Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

On Linux systems, you can successfully chmod u+s $some_directory, but instead of forcing the ownership of new subdirectories and files to be the owner of the containing directory (and setting subdirectories u+s as well) as you might expect, the system just ignores the setuid bit. Subdirectories and files continue to inherit the UIDs of their creating processes, and subdirectories are not setuid by default.

Why is setuid ignored on directories, and how can I get the system to recognize it?

share|improve this question
    
I wonder if the "nosuid" mount option can affect this. –  Heptite Sep 9 '12 at 0:51
    
The filesystem in question isn't mounted with nosuid—though there's another one (a ramdisk, /dev/shm) which /is/ mounted nosuid, and it seems to treat the setuid bit exactly the same way. 6_9 –  Blacklight Shining Sep 9 '12 at 3:53
1  
See also: serverfault.com/questions/371541/… –  jjlin Sep 9 '12 at 23:21
    
As to implementing it, Linux sourcecode is readily available, feel free to implement this feature. Since it already exists on FreeBSD, you could quite easily copy the code over I'm sure. Of course, those bits would still have no meaning on anyone else's Linux system. –  mikebabcock Sep 20 '12 at 3:18
add comment

4 Answers

up vote 3 down vote accepted

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.

share|improve this answer
    
I would like it implemented, if only for consistency's sake… X3 In any case, short of a workaround like a cronjob to periodically go through and change the ownership, /is/ there any way to force the file ownership? –  Blacklight Shining Sep 9 '12 at 3:51
2  
I'm tempted to quote Emerson on Foolish Consistency. Before you can convince me that it's a desirable feature, you'll have to show me a use case where it makes sense. –  Isaac Rabinovitch Sep 9 '12 at 7:07
1  
FreeBSD chmod(2) actually has some discussion of this, but mentions only that it shouldn't generally be used due to unspecified "security holes". I suspect most other Unixes didn't adopt this feature because while it does have some use cases, it's not that terribly useful. –  jjlin Sep 12 '12 at 2:20
    
While the above is a logical reason for it to not be implemented, if we're being pedantic (and it seems we are) it isn't the reason until someone finds the people on the lkml who decided not to implement it. –  mikebabcock Sep 20 '12 at 3:16
    
"Hard to see the utility of that" -> set on a home directory, so provision scripts running as root can't forget to chown something by accident? –  ufotds Apr 29 at 22:46
show 1 more comment

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

share|improve this answer
1  
This does not seem to address the question that was asked. –  Kevin Panko Feb 5 at 15:49
    
@KevinPanko No, it doesn't answer my question. It might even be off-topic for the site (“what is a use case for <nonexistent feature X>?”). However, it does pertain to my question, and I, as the asker, find it useful. –  Blacklight Shining Feb 6 at 15:13
add comment

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.

share|improve this answer
add comment

According to http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories the setuid bit is ignored for directories on both UNIX and Linux systems. Its possible to make it act as you expect on FreeBSD however.

share|improve this answer
    
Not helpful—I asked why setuid was ignored for directories and if it was possible to make it recognized on Linux. –  Blacklight Shining Sep 9 '12 at 3:37
    
It seems obvious that its ignored on Linux because its ignored on Unix, which makes it correct behaviour for Linux to fit in with real *nix. Feel free to read the article in question. Same answer at greenend.org.uk/rjk/tech/perms.html from 2004, also a duplicate of serverfault.com/questions/371541/… –  mikebabcock Sep 10 '12 at 0:05
    
So why is it ignored on Unix? –  Isaac Rabinovitch Sep 10 '12 at 0:24
    
@IsaacRabinovitch since Blacklight made it clear the question is about Linux, that's not relevant [tongue in cheek] but I suspect its simply undefined behaviour where multiple Unixes did different things with it and doing nothing is a safer assumption. –  mikebabcock Sep 10 '12 at 0:27
    
The question /is/ tagged linux, yes, but that doesn't mean I'll prefer a vague “It's done this way because other systems do it this way” answer to an answer that explains why it is done that way on other systems. (Maybe the linux tag should simply be removed?) –  Blacklight Shining Sep 10 '12 at 6:49
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.