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?

  • I wonder if the "nosuid" mount option can affect this.
    – Heptite
    Sep 9, 2012 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 Sep 9, 2012 at 3:53
  • 1
    See also: serverfault.com/questions/371541/…
    – jjlin
    Sep 9, 2012 at 23:21
  • 2
    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. Sep 20, 2012 at 3:18

6 Answers 6


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.

  • 7
    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. Sep 9, 2012 at 7:07
  • 2
    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, 2012 at 2:20
  • 2
    "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, 2014 at 22:46
  • 1
    running superuser scripts in your home directory is a really bad idea Apr 30, 2014 at 1:58
  • 2
    @IsaacRabinovitch I'm not saying this necessarily merits implementation of the feature, but here is one use case I have run into. Copy a file from a remote machine to a server running a daemon automatically reads and writes to that file. My actual solution to giving permissions to the daemon user involves using rsync's --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.
    – fvgs
    Dec 28, 2016 at 16:05

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

  • 1
    This does not seem to address the question that was asked. Feb 5, 2014 at 15:49
  • 3
    @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. 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
  • Welcome to Stack Exchange! This is a good answer, though as it relates to OS X rather than Linux distros (which, as you mentioned, use a different ACL system), it doesn't quite seem as relevant here. It would definitely be a good fit on a question about how to make OS X honor setuid directories; maybe you should post one? Nov 22, 2015 at 1:03
  • By the way, the bit you left out from OS X's manual page on 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
  • 1
    (And OS X ACLs are just as “not really visible at first glance” as Linux ACLs are.) Nov 22, 2015 at 1:07

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.


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.

  • Not helpful—I asked why setuid was ignored for directories and if it was possible to make it recognized on Linux. Sep 9, 2012 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/… Sep 10, 2012 at 0:05
  • So why is it ignored on Unix? Sep 10, 2012 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. Sep 10, 2012 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?) Sep 10, 2012 at 6:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .