Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this community
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?
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.
--chmod (since my umask is 0022). But a simpler way to go about this (if the feature were implemented) would be setting the setuid bit on the directory the daemon is watching. Incidentally, my system doesn't support the setgid bit either, so that's also not a viable option.
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
<nonexistent feature X>?”). However, it does pertain to my question, and I, as the asker, find it useful.
Feb 6, 2014 at 15:13
A bit late to the party, but in case future readers stumble across this ;)
As stated by others, on a standard OS-X filesystem the setUID for directories gets ignored - and there doesn't seem to be an easy way around this (mount -o .... or what not). As so often, the man page actually does not comply with the OS-X behaviour it literally states:
4000 (the set-user-ID-on-execution bit) [...] Directories with the set-user-id bit set will force all files and sub-directories created in them to be owned by the directory owner and not by the uid of the creating process [...]
but it also lists a possibility to achieve the same effect without giving up the original ownership. Linux uses '[g/]setfacls' for similar effects (they're permissions not really visible at first glance, so can sometime be a nuisance).
As to the 'how can I achieve similar effects', read the entire man page and fiddle with:
chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]
you can check via
ls -le
if all looks fine. Further options include inserting rules at specific positions, removing or replacing specific rules. The two noteworthy options here are "file_inherit and directory_inherit" allowing the rules to be attached to a new directory/file.
I'm not really fond of using setUID, but setGID comes in very handy on fileservers where simply setting the 'main' group doesn't work or clients have filemasks disallowing group write. That would be solved by:
chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup
chown actually seems pretty important! “[…] if the underlying file system supports this feature: see chmod(2) and the suiddir option to mount(8).” I actually hadn't ever noticed that bit before. If HFS implements suiddir, you can actually get this to happen on a common OS X system.
Nov 22, 2015 at 1:06
Well, it should respect the standard. I can think on quite a few scenaries with sftp-only that it would save me a lot of trouble, both with acl's and the acl-mask-set that sshd does, and the reset that i must do to that mask.
Security by default is quite usefull, but if you dont make it an option, you are just creating a winghtmare.
https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html
Either way, it is as Linux goes now, so just use acl's to work around those.
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.
setuid was ignored for directories and if it was possible to make it recognized on Linux.
Sep 9, 2012 at 3:37
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?)
Sep 10, 2012 at 6:49
nosuid—though there's another one (a ramdisk,/dev/shm) which /is/ mountednosuid, and it seems to treat thesetuidbit exactly the same way. 6_9