permissions

[Todd Anderson]

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.

 

[Walter Roberson]

: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
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.

 

[Todd Anderson]

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.

: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
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

 

[Walter Roberson]

: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.

 

[Todd Anderson]

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??

: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.

--
<•˜ }}}} ><<
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

 

[Walter Roberson]

: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.