No 777 Perms

October 14, 2004 6:50 AM

Is there any way to write to a directory via a script without giving both the directory and the script 777 perms? More specifically the script is writing to a different directory than it is in and I cannot write to that directory without giving it 777 perms. This is a Linux server using Apache web server.
posted by thebwit to Computers & Internet (8 answers total)

One way is to have the script create the directory. Then it will be owned by the script and only needs 700 perms.
posted by smackfu at 7:01 AM on October 14, 2004

The script only needs execute (and probably read, if it's not compiled), and it only needs those permissions to be set for the user that it's running as. What user that is depends on how your webserver is set up. In other words, the script only needs a "1" (or probably a "5") in one position of the octal/numeric permission setting in order to be executed properly. (It's usually convenient if you can execute it, too, for when you're developing and debugging. That requires a "5" in the first position.)

The directory the script writes to is more-or-less the same: it only needs a "2" (or more likely a "7") in one of the positions in order for your script to write to it. The other permission categories apply to other users.

Take a closer look at the chmod(3) manpage, and play with various permissions until you understand what's going on. (I'm only assuming you don't have a good idea of what's going on...if you do understand, please forgive me this paragraph.) If you have the script create some random file in /tmp, you can discover what user and group it's running as, and set your ownership and permission appropriately.
posted by spacewrench at 7:04 AM on October 14, 2004

I've wondered about this myself. I get the user ownership aspect, but we run apache as "nobody", since it's a user that has no logon, shell, nuthin'. Does UNIX still recognize nobody/nobody as a valid user/group combination for the sake of permissions?
posted by mkultra at 7:34 AM on October 14, 2004

Response by poster: Thats the problem mkultra, is that it creates the file within the Nobody, Nobody and thus I need full permissions for some unknown reason. I have played with every combination that I can think of that makes sense and 777 seems to be the only one that works. Going with the Owner, Group, Everyone I have done the following: 7 2 2 - this should give it the ability to write to it, but nope because it doesn't have read rights on the directory. So from there we go to 766 which gives it read/write, but no wait can't execute it. So ignoring that one, we go back and try 733 (write/execute) but run into the can't read the directory problem. Ok we try 755 but well that removes write permission. Thus 777 seems to be the only thing that works.

As far as having the script create the directory that is a no go because of what the script is going to do.

I have also tried having the script create the file in the same directory and then moving the script, but again we run into the read/write/execute problem as described above.
posted by thebwit at 7:43 AM on October 14, 2004

Whether or not what you're asking for is reasonable or safe depends on whether or not you "own" the box.

If it's your server then this will work:

Simply make the subdirectory that you want the code to write to owned by nobody. Alternatively, you could create a new group, add the user nobody to the group, make the directory owned by the new group, and make it group writeable.

If you don't own the server, those tasks may be difficult/impossible. You might be better off writing whatever it is you're writing to a database.
posted by jaded at 7:56 AM on October 14, 2004

Having the script create the directory won't solve the problem, because the directory in which that directory resides would still need to be 777'd before Nobody/Nobody can write to it.

I assume the script in question is PHP, because I've dealt with this problem numerous times before. Depending on how much control you have of the server, you can do several things:

1. Write the script in Perl. Perl generally runs as your userid/group, so you own the file once created. In that way, the directory in which the file is written requires no particular permissions for the script to function.

2. Make sure that PHP on the server is configured to not read anything outsite of a user's homedir, and place the 777'd directory outside your webroot. This prevents people from attempting to exploit said weakness without limiting PHP's ability to read/write files.

3. Find a CGI wrapper for PHP, which allows PHP to run as your userid/group. Be aware that this may impact speed and memory consumption. I believe this is one.

4. Create a Perl script that changes permissions on that directory before and after PHP writes to the file, and invoke those commands at the appropriate time using exec(). Frankly, having PHP installed on a server where exec() (or passthru() or system() or backticks or their ilk) are enabled is FAR more dangerous than a single 777'd directory.
posted by Danelope at 8:17 AM on October 14, 2004

Why don't you just make the part of the script that needs to write to the directory setuid?
posted by rdr at 9:11 AM on October 14, 2004

thebwit: It's an exceedingly bad idea for files to be owned by nobody in the first place -- in fact it completely negates the point of having services that run as nobody.

It sounds like what you are looking for is suexec.
posted by majick at 1:09 PM on October 15, 2004