Phoenix.pm: UNIX permissions

[Phaedrus]

> From: Beaves at aol.com
> 
> I am having a bit of trouble with UNIX file permissions.  Is a script 
> considered an 'other' user?

A script runs with the permission of the person that runs it. When a
person runs a program that runs a program, the last program runs with that
persons permissions. However, for security reasons, many programs (like
apache) wish to be run as root, so that they may switch which user they
run as. Apache, depending how it is configured, will run as the user
specified in the config file (usualy nobody or httpd or somesuch), or it
will switch to the owner of the script immediately before it runs the
script.
I guess this is sort of important to know how the server is configured.
Usualy, when I have to write a script on a strange machine, the first
thing I do is read the apache config files.
Usualy you are safe if you do:
chmod ugo+rx *
This lets anyone read and/or run files in the current directory. If your
script does not need to write to files in the directory, this is adequate.
To make it so that the script can write to a file in the current
directory, its very helpful to know what user your scripts are being run
as (your user id, a generic one, etc). The "quick and dirty" fix is to
make the directory readable/writtable/searchable by anyone (chmod ugo+rwx
.), make Perl program run with umask 0000, and chmod 666 the files it
needs to read/write, before it runs. This is not a secure thing to do. If
you can add read/write privs only to the group you are much better off. 
Likewise, you don't want everyone having read access if you are storing
sensative information...
In complex cases like this, the correct thing to do is have the web server
run "chroot", have a custom group created just for the application (if it
is a collobrative project, or a custom user created atleast), and have the
webserver set to switch to the permissions of the owner of the cgi-bin
programs it runs (this would cause the webserver to get the group members
of the user as well).

> 
> Would anyone care to enter into a short discussion about the hows and whys of 
> the best way to run directory and file permissions?  What should directories 
> and files used by a particular script be set to and why?

Permissions on most of the system are set up in an exact way: some files,
certain groups need r/w to. Others need not be even readable by anyway,
but can be executed by anyone. Someone need the special 'setuid' bit set.
However, users home directories can be fiddled with. Generally, people
should have access to their home directory: read, write and execute. If
all users are in a generic 'users' group, you may not want to give the
home directories group read write execute permissions, though alot of
systems are setup so that users may read each others files by default. It
is customary for users to own their directory. Sometimes "other" has read
and execute access as well, by default, but not nearly as often as
"group".
A good way to limit the damage that intruders (or customers) can do is
create a user for each web project, 
and to run scripts as the owner/user of that web (another option). 
That coupled with users having access to their stuff, .htaccess files,
other and group not having any permissions... should create an environment
where you can create files all day, without worry of other people
reading/writting/listing them.
If you are really concerned, use the apache chroot option, so that scripts
cant see any of the harddrive outside of that web projects directory. You
will have to install Perl and its modules in each web though....

> 
> Does a directory's permissions affect each and every sub directory? or just 
> the files immediately below it?

The permissions affect only the current directory or file. However,
since the system has to start at the root directory (/), and crawl
downwards when it follows a path, at any point someone may be denied
access to all content in subdirectories if they dont have read or search
(execute) access to one of the directories in the path. This lets you
"sort of" create protected areas, where you can have liberal permissions:
read write execute for everyone, and keep people out of it, because they
can't get there, because part of the path is blocking them. However, this
is not secure. Even though a person as themselves may never be able to cd
there, the web server must be able to, and it is quite easy to get the
webserver to do this kind of dirty work for you (reading, atleast).
If the webserver can't be provoked to, there is always something else that
can... but lets not get into that here.

> 
> One specific question...  I gave a directory write permissions, but the 
> script was not allowed to create a new file to that directory until I gave it 
> execute permissions.  Why is that?
> 

The chmod 111 or ugo+x bit is sort of "overloaded". For files, it means
you can run them like a program. For a directory, it means that you may
search the directory (cd into it, etc).

> 
> Thanks for your help...

You will regret having accept my help... they always do... bwahahahahah!!!
> 
> Tim
> 
> 
>