php & filesystem +setUID/permissions ... i just don't get it!

i have to admit, i never really completely got the *nix filesystem permission model. oh, the rwxrwxrwx stuff isn't too complicated, but i get confused easily when programs create new files and how i can handle them.

my current problem is the mixture of a (closed source) java-applet that does file uploads over ftp and php (it's on a dedicated server and the data isn't really critical, so i'm not all too concerned about world-writeability).

so, i have two users: ftp (1000) and apache/php (81). groups don't match, so they're basically "others", if i'm correct.

an "import" directory, set to 0777 owned by ftp.

if a visitor acesses the upload page, a subdirectory named after his username is created by my script. let's say, the visitors username is "foo", so it's "import/foo", set to 0777, user 81/php.

next, the visitor uses the java applet to upload a file to this directory (test.jpg). the file's permissions are now rw-r--r--, user ftp.

first question

the first thing i don't understand is: i'm able to unlink that file through php.

why? the users don't match, and the file isn't world writeable.

is this because of the parent directories world-write permission? understandably, i can't chown or chmod through php.

so far no problem, because as long as i can read and unlink, everythings ok.

second question

the java applet is able to upload whole directories, which is nice. if i do this, the new subdirectory import/foo/test has permissions rwxr-xr-x/ftp. the files in this directory are rw-r--r--/ftp.

now i'm out of luck. i can't do anything with those files (besides reading, which i do successfully), no unlinking, no chmod/chowning. they just sit around and gobble up diskspace.

so, what's the plan behind the default-permissions new files have? my guess is they have the permission set through umask, as long the creating sc开发者_运维知识库ript doesn't chmod them to something else. am i right?

third question

what can i do about it? i mean, what would a sensible person do? can i/should i change the umask for the ftp user? (i just learned about umask yesterday). i'm not very comfortable with this, as this would affect all ftp traffic, doesn't it? also, the server is dedicated but i'm not an admin, so my access is restricted.

i just had another idea. before starting this post i read up on the basic linux permission stuff. first, the sticky bit isn't set anywhere in the directory chain. and then, there it was: the "set user ID bit".

so, my current plan is to write a simple shell script with owner ftp that is other-executable with setuid. the script just transfers the file in the import directories ownership to user php.

then, after each import i just exec() that file from my php-script and process files further.

would that work? and more important: is that clean and legal? or would the sysadmin put a bounty on my head?

thx a lot!

update: i just tried to set the uid bit (4755) through winscp (through an ftp connection), but it somehow doesn't work - it seems to "forget" only the uid bit (the other bits get set). why is that? why can't the owner set the uid himself? is that server-specific or generally the case?

update 2:

wikipedia says it all

Due to the increased likelihood of security flaws, many operating systems ignore the setuid attribute when applied to executable shell scripts.

is it still possible for user root to set the uid-bit?

First answer

Correct, you have permission to modify the directory so you can unlink the file. Whether that file is readable or writable to you is irrelevant.

Second answer

Yes you are correct that the user's default umask will be used unless the script/applet then chmods the file permissions to something else

Third answer

Setting the default umask for ftp is the simplest solution, but as you say this affects all files then created by the ftp user. If that user is only used for the upload via the applet (and it should be really) then this isn't really an issue I'd say.

The other option is to have a cron job running that executes a script (like you suggest), chmoding/owning the files (and maybe virus scanning them etc) from the FTP upload area to somewhere on the webroot.

You don't state why having these files readonly to Apache is an issue (or is it the fact that the FTP root isn't under the web root?), maybe clarifying that would help point to a sensible solution? Generally you don't want to trust anything the user has given you unless you've vetted it first.

EDIT - just seen you're not an admin of the machine which makes things difficult.

what i learned today: the setuid bit is often deactivated for scripts.

the solution i've settled on: apache/php gets sudoer-rights for certain scripts (all scripts in one directory outside the webroot) that may run as either the ftp- or apache-user. i can then call those scripts with sudo out of php with system/exec/etc.

i didn't know sudo could be configured in this way. amazing