Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Arrrg! Permissions driving me nuts in PHP [SOLVED]



s smith writes:

 > On 11/25/2010 9:21 PM, Stephen J. Turnbull wrote:
 > > Even if it works, you don't want to do that.  It opens your system up
 > > to potential directory traversal and trojan attacks because there's a
 > > race condition.
 > >
 > It would only open for the process -- umask for file creation for this 
 > process and maybe its children, right?

Yes, *but those 0777 permissions are written to disk by mkdir*.  This
opens up the possibility that other processes will screw with your
data.  That's why I wrote "race condition", there has to be somebody
else out there to race with.  Here the race is "until I remove that
directory".

 > Also, nobody is a special user (user id #2 I think), right?  I think 
 > it's a restricted user -- but am not sure exactly how it's restricted 
 > user but am not sure what the restrictions are.

Normally, nobody is an ordinary user, typically with uid = (uid_t)
(-2).  The restrictions are implemented using standard mechanisms by
making nobody a member of no groups.  That's all.  This means that
with standard 06.4 or 07.5 perms nobody can look but not touch
anybody's stuff, and with 06.0 or 07.1 or 07.0, nobody can't even
look.  However, some app writers who didn't think about the
implications started using "nobody" as the owner of their server
processes.  But suppose you run both Apache and PostgreSQL as
"nobody".  Now both can read and write each others's stuff!  Ouch!

It's a very bad idea to have file system objects owned by nobody for
this reason, unless you really want unauthenticated users writing to
your file system.



Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links