permissions

Discussion in 'Perl Misc' started by Todd Anderson, Jan 30, 2004.

  1. hello,
    I recently moved my site from a virtual server where every perl script I
    uploaded was owned by the default user 'nobody'. I could set permisions
    on a user dir of 644 and the user file of 755. This worked fine.
    Now with my new host where I have root access the default upload owner
    is me the user. I now have to set permisions to 755 and 777 just to get
    the script to run. I'm not sure what the problem is.
    Any help is appreciated and thanks in advance.
    Todd Anderson, Jan 30, 2004
    #1
    1. Advertising

  2. In article <>,
    Todd Anderson <> wrote:
    :I recently moved my site from a virtual server where every perl script I
    :uploaded was owned by the default user 'nobody'. I could set permisions
    :eek:n a user dir of 644 and the user file of 755. This worked fine.
    :Now with my new host where I have root access the default upload owner
    :is me the user. I now have to set permisions to 755 and 777 just to get
    :the script to run. I'm not sure what the problem is.

    That's not a perl question.

    You probably don't need 777 on the user files, just 755. Probably the
    755 on the directory was what did the trick. 644 permissions on the
    directory doesn't allow "x" permissions on the directory by anyone,
    which means that no-one can use that directory as part of a pathname to
    reach a file -- but they can still use "ls" to look to see what files
    are there. This becomes more important when the WWW server is not
    running under the same userid as owns the directories.
    --
    Scintillate, scintillate, globule vivific
    Fain would I fathom thy nature specific.
    Loftily poised on ether capacious
    Strongly resembling a gem carbonaceous. -- Anon
    Walter Roberson, Jan 30, 2004
    #2
    1. Advertising

  3. Additionally, when the script writes an authentication file it defaults to
    644 which won't let the script in turn read it to authenticate. go figure.

    Walter Roberson wrote:

    > In article <>,
    > Todd Anderson <> wrote:
    > :I recently moved my site from a virtual server where every perl script I
    > :uploaded was owned by the default user 'nobody'. I could set permisions
    > :eek:n a user dir of 644 and the user file of 755. This worked fine.
    > :Now with my new host where I have root access the default upload owner
    > :is me the user. I now have to set permisions to 755 and 777 just to get
    > :the script to run. I'm not sure what the problem is.
    >
    > That's not a perl question.
    >
    > You probably don't need 777 on the user files, just 755. Probably the
    > 755 on the directory was what did the trick. 644 permissions on the
    > directory doesn't allow "x" permissions on the directory by anyone,
    > which means that no-one can use that directory as part of a pathname to
    > reach a file -- but they can still use "ls" to look to see what files
    > are there. This becomes more important when the WWW server is not
    > running under the same userid as owns the directories.
    > --
    > Scintillate, scintillate, globule vivific
    > Fain would I fathom thy nature specific.
    > Loftily poised on ether capacious
    > Strongly resembling a gem carbonaceous. -- Anon


    --
    <•˜ }}}} ><<
    Regards

    Todd Anderson
    ASGWEB.net
    1362 East 3345 South
    Salt Lake City, Utah 84106 USA
    801.487.3675

    http://asgweb.net
    http://JesusThing.com
    http://www.DocuHarbor.com
    http://www.christianlink.com/search/index.cgi
    http://TV20.org
    http://asgweb.net/asgpro
    http://SecureShip.com
    http://MrNoItAll.com
    Todd Anderson, Jan 30, 2004
    #3
  4. In article <>,
    Todd Anderson <> wrote:
    :Additionally, when the script writes an authentication file it defaults to
    :644 which won't let the script in turn read it to authenticate. go figure.

    Sounds like directory permissions. The permissions such as 644 are
    in three clusters of 3 bits each (octal), with the first cluster
    controlling access for the owner, the second controlling access
    for those belonging to the same unix group, and the third controlling
    access for everyone else. Within each cluster, the first bit
    (numeric value 4) controls read access, the second bit (numeric value 2)
    controls write access, and the third bit (numeric value 1) controls
    execute access [files] or search access [directories.]
    Thus, 644 is read (4) + write (2) = 6 and no execute access
    for the file owner, and just read (4) access for the group and
    just read access (4) for everyone else. So with 644 permissions,
    everyone *has* read permissions on the file... provided they can
    get through the permissions hierarchy on the directory structure
    that names the full file.


    There is one other possibility that can end up giving wierd results.
    If the system supports Access Control Lists (ACLs), then sometimes
    whether a given ACL entry bit is in effect or not is controlled
    by the standard permission bits. For example, with 644 permissions,
    instead of the last 4 meaning "everyone else is allowed to read
    this", the 4 could mean that "in the ACL associated with this file,
    pay attention to whatever read permissions are given by the ACL,
    but ignore any write or execute permissions given in the ACL."
    And if that's happening [e.g., SGI's IRIX] then you need to look
    at the details of the ACL.

    In systems that have ACLs, the last character of the ls -l
    permissions list often shows up as a plus sign:

    $ ls -ld ~radm/hosts
    -rw-rw-r--+ 11 root sys 75953 Jan 26 15:32 /usr/local/sysadm/rdist/hosts

    To see the ACL contents, you may have to add an extra option to ls:

    $ ls -ldD ~radm/hosts
    -rw-rw-r--+ 11 root sys 75953 Jan 26 15:32 /usr/local/sysadm/rdist/hosts [u::rw-,g::rwx,o::r--,u:ken:rwx,u:bob:rwx,u:nancy:rwx,u:cheryl:rwx,u:ritchie:rwx,u:kerningham:rwx,m::rw-]


    But none of this has to do with perl.
    --
    Rump-Titty-Titty-Tum-TAH-Tee -- Fritz Lieber
    Walter Roberson, Jan 30, 2004
    #4
  5. checked and there is NO ACL.
    if i change my default user from 'nobody' to 'me', the script can read it's own authentication files and everything else works fine. is there a danger in doing this?
    why did 644 work on the user directory on the other server?
    if a script is ownwed by 'user' and some one prompts the script from the browser, doesn't the server see that action as by the owner (user)? if so, shouldn't 700 be the best choice for a dir
    that needs to be read, write, and execute by the script??

    Walter Roberson wrote:

    > In article <>,
    > Todd Anderson <> wrote:
    > :Additionally, when the script writes an authentication file it defaults to
    > :644 which won't let the script in turn read it to authenticate. go figure.
    >
    > Sounds like directory permissions. The permissions such as 644 are
    > in three clusters of 3 bits each (octal), with the first cluster
    > controlling access for the owner, the second controlling access
    > for those belonging to the same unix group, and the third controlling
    > access for everyone else. Within each cluster, the first bit
    > (numeric value 4) controls read access, the second bit (numeric value 2)
    > controls write access, and the third bit (numeric value 1) controls
    > execute access [files] or search access [directories.]
    > Thus, 644 is read (4) + write (2) = 6 and no execute access
    > for the file owner, and just read (4) access for the group and
    > just read access (4) for everyone else. So with 644 permissions,
    > everyone *has* read permissions on the file... provided they can
    > get through the permissions hierarchy on the directory structure
    > that names the full file.
    >
    > There is one other possibility that can end up giving wierd results.
    > If the system supports Access Control Lists (ACLs), then sometimes
    > whether a given ACL entry bit is in effect or not is controlled
    > by the standard permission bits. For example, with 644 permissions,
    > instead of the last 4 meaning "everyone else is allowed to read
    > this", the 4 could mean that "in the ACL associated with this file,
    > pay attention to whatever read permissions are given by the ACL,
    > but ignore any write or execute permissions given in the ACL."
    > And if that's happening [e.g., SGI's IRIX] then you need to look
    > at the details of the ACL.
    >
    > In systems that have ACLs, the last character of the ls -l
    > permissions list often shows up as a plus sign:
    >
    > $ ls -ld ~radm/hosts
    > -rw-rw-r--+ 11 root sys 75953 Jan 26 15:32 /usr/local/sysadm/rdist/hosts
    >
    > To see the ACL contents, you may have to add an extra option to ls:
    >
    > $ ls -ldD ~radm/hosts
    > -rw-rw-r--+ 11 root sys 75953 Jan 26 15:32 /usr/local/sysadm/rdist/hosts [u::rw-,g::rwx,o::r--,u:ken:rwx,u:bob:rwx,u:nancy:rwx,u:cheryl:rwx,u:ritchie:rwx,u:kerningham:rwx,m::rw-]
    >
    > But none of this has to do with perl.
    > --
    > Rump-Titty-Titty-Tum-TAH-Tee -- Fritz Lieber


    --
    <•˜ }}}} ><<
    Regards

    Todd Anderson
    ASGWEB.net
    1362 East 3345 South
    Salt Lake City, Utah 84106 USA
    801.487.3675

    http://asgweb.net
    http://JesusThing.com
    http://www.DocuHarbor.com
    http://www.christianlink.com/search/index.cgi
    http://TV20.org
    http://asgweb.net/asgpro
    http://SecureShip.com
    http://MrNoItAll.com
    Todd Anderson, Jan 30, 2004
    #5
  6. In article <>,
    Todd Anderson <> wrote:
    :if a script is ownwed by 'user' and some one prompts the script from
    :the browser, doesn't the server see that action as by the owner (user)?

    Again, that isn't a perl question, but to answer it:

    No, a http server usually runs as a specific user (probably 'nobody'
    on your new system), and usually attempts all accesses as that
    user. Apache2 [and possibly some others] have provisions for
    automatically accessing some hierarchies by becoming other users;
    I have never looked into how that is configured. It is, though,
    pretty much unknown for the http server to temporarily become
    the owner of each and every file prior to trying to use that file.
    Suppose you, in one of your pages, made a reference to someone else's
    sensitive file: it wouldn't be good for the server to automatically
    become them so that it could show you the content of the file that
    shouldn't be accessible.
    --
    Entropy is the logarithm of probability -- Boltzmann
    Walter Roberson, Jan 30, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Kamoski
    Replies:
    7
    Views:
    8,639
    Mark Kamoski
    Aug 9, 2003
  2. Geno

    Permissions

    Geno, Dec 20, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    607
  3. Geno

    permissions

    Geno, Dec 20, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    536
  4. Scott Allen
    Replies:
    0
    Views:
    431
    Scott Allen
    Jul 13, 2004
  5. Curt K
    Replies:
    0
    Views:
    561
    Curt K
    Nov 3, 2006
Loading...

Share This Page