Why is setuid ignored on directories?

Recall that the setuid and setgid bits were invented for a completely different purpose: causing an executable to run with its owner's uid or gid, rather than the uid or gid of the user running the file. Any other usage is just an extra feature.

These bits have no function on ordinary files that aren't executable. (And also shell scripts on some distros, due to security issues.) Originally, they also had no function for directories. Obviously somebody decided it would be cool to take the unused setgid on directories and use it to enforce consistency of group ownership. After all, if you're playing with group ownership, it's because more than one person is working with the file, and it probably makes sense for all the files in a given directory to belong to the same group, no matter who created them. Hassles due to somebody forgetting to run newgrp are eliminated.

So, why not implement the same feature for setuid and the file uid? Well, uid is much more basic than gid. If you implement this, often a file will not belong to the user who created it! Presumably the user can still modify the file (assuming the umask is something sane), but they can't change the permission bits. Hard to see the utility of that.

I believe that the answer to this question bears on the "file giveaway" security issues that have resulted in most modern Unix-like OSes not permitting "file giveaway". "File giveaway" is when a non-superuser user changes the ownership of a file to someone other than that user. This capability provides many opportunities for mischief.

Since file giveaways are not permitted, setuid on directories, which would perform the same function in another form, is not permitted, or ignored if set.

As to changing the behavior, you would have to modify OS libraries and utilities.

One very good use case for implementing it is this:

Lets say you have a multi-site server with 3 secure sites. You have 3 groups created, one for each of the different sites maintainers. All of the files in all of the sites need to be owned by the apache user so that apache can read and write to them (drupal/wordpress, etc).

If the setuid but worked like the setgid bit for directories permissions would look something like this:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

This way each group of maintainers had access to see and touch only their content but the web server user apache could serve all content and there is no need for users to worry about changing the ownership of uploaded files.

Another use case is for Anonymous ftp/http or even sftp/ssh uploads. The group and GID on the upload directory would be root and so would the owner and UID. The other permissions would be -wx. This would allow everyone WRITE access to the upload directory but they could not read anything once it was uploaded and root would own all files newly created.

So there are two perfectly good and valid use cases for enabling the UID functionality on directories to match the GID bit.

Steven Mercurio