Does any Unix-like system ascribe meaning to the SUID bit on a directory?

Question

As the title says, does any Unix-like system ascribe a meaning to the SUID bit on a directory, and if so, what does it mean?

The SVTX (saved text, or sticky) bit has a meaning - thou shalt not delete a file from this directory unless you can write to the file. It is used on /tmp, for example.

The SGID (set GID) bit has a meaning - files created in this directory shall belong to the group that owns the directory (though that assignment can later be changed by an explicit call to chown(2)).

What about the SUID bit?

score 6 · Accepted Answer · answered Mar 09 '09 at 20:36

As a followup on Node's answer, I will post the following from the FreeBSD man page for mount(8):

             suiddir
                 A directory on the mounted file system will respond to
                 the SUID bit being set, by setting the owner of any new
                 files to be the same as the owner of the directory.  New
                 directories will inherit the bit from their parents.
                 Execute bits are removed from the file, and it will not
                 be given to root.

                 This feature is designed for use on fileservers serving
                 PC users via ftp, SAMBA, or netatalk.  It provides secu-
                 rity holes for shell users and as such should not be used
                 on shell machines, especially on home directories.  This
                 option requires the SUIDDIR option in the kernel to work.
                 Only UFS file systems support this option.  See chmod(2)
                 for more information.

And the chmod(2) man page section that refers to the suid bit:

           4000    (the setuid bit).  Executable files with this bit set will
               run with effective uid set to the uid of the file owner.
               Directories with this 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, if the
               underlying file system supports this feature: see chmod(2)
               and the suiddir option to mount(8).

Please be aware that this is a security risk and know what you are doing when you enable it, in FreeBSD but I believe Linux as well it requires special mount flag to be enabled and will change the way files in that directory behave.

Thank you - that is helpful because it includes specific platform information. Other messages I've seen only include the general assertion that such systems exist. — Jonathan Leffler, Mar 09 '09 at 20:51
Hm, could you describe a scenario where it would be a security risk to use it? Maybe if _secret_ files from a user would be created as _nobody_. But nice to know. :) *upvote* — Node, Mar 09 '09 at 20:53
@Node: Not sure how it could be used as a security hole, other than that it is generally considered bad practice, and therefore it has been disabled by default in FreeBSD/Linux. — X-Istence, Mar 09 '09 at 22:09
Note creat(2)'s second parameter allows the attacker (Mallory) to specify file mode. Imagine Alice has a setuid directory, Mallory has write access. Mallory creates a file in this directory with permissions 4555 (ie executable, SUID). File is automatically chowned to Alice. Mallory pwns Alice. — Martin Carpenter, Mar 09 '09 at 22:36
@Martin Carpenter: The FreeBSD implementation already accounts for that, it won't allow you to create files that are chmod'ed to +x, it always removes the execute bit from the files that are created, but it does not mention what happens when you move a setuid file to the setuid directory! — X-Istence, Mar 09 '09 at 23:12
The security hole is very simple - many programs use the fact that a config/script/etc. file is owned by the expected user as a sign to trust it with that user's credentials. For instance a web server might run scripts owned by `alice` as `alice`. If I can create a file owned by `alice` by creating it in a suid-`alice` directory, then create a hard-link to it somewhere where config files or scripts go, I might be able to compromise the account. — R.. GitHub STOP HELPING ICE, Mar 28 '11 at 21:46

score 4 · Answer 2 · answered Mar 09 '09 at 20:28

Copied from here:

On most systems, if a directory's set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. On a few systems, a directory's set-user-ID bit has a similar effect on the ownership of new subfiles and the set-user-ID bits of new subdirectories. These mechanisms let users share files more easily, by lessening the need to use chmod or chown to share new files.

These convenience mechanisms rely on the set-user-ID and set-group-ID bits of directories. If commands like chmod and mkdir routinely cleared these bits on directories, the mechanisms would be less convenient and it would be harder to share files. Therefore, a command like chmod does not affect the set-user-ID or set-group-ID bits of a directory unless the user specifically mentions them in a symbolic mode, or sets them in a numeric mode.

Thanks - that is a helpful pointer. Do we have any information about which systems support the "on a few systems, a directory's set-user-ID bit has a similar effect"? It seems like an obvious extension of the set-group-ID feature. What security consequences would it have? — Jonathan Leffler, Mar 09 '09 at 20:31
Hm, good question on my linux (coreutils-5.93) it does not show this behavior. ATM I can't see any real security problems if it would act like described. — Node, Mar 09 '09 at 20:47

John Ellinwood · Answer 3 · 2009-03-09T23:48:33.320

1

When set on a directory, all the files and directories created within this directory will have the same owner as the SUID-directory itself, no matter who created the file. This is a feature which is not used too often, but it can be useful in some cases. (source)

Update: I just tried this on Linux 2.6.25.5-1.1-default #1 SMP x86_64 GNU/Linux openSUSE 11.0 (X86-64).

mkdir tmp
chmod 4777 tmp
su othergroup
touch testfile

It had no effect.

edited Mar 09 '09 at 23:48

answered Mar 09 '09 at 20:26

John Ellinwood

14,291
7
38
48

Do you know of any systems which actually support it - the URL says it happens, but I'm not clear on which platforms. – Jonathan Leffler Mar 09 '09 at 20:49
@John: You've demonstrated SGID on directory, not SUID. Solaris and Linux support SGID on directories out of the box. – Martin Carpenter Mar 09 '09 at 22:38
bah, you're right. i tried 4777 and it didn't do anything, so I guess OpenSuSE doesn't do anything with it. Wikipedia also says only FreeBSD uses it, too. – John Ellinwood Mar 09 '09 at 23:48
SGID works on FreeBSD too, SUID however requires kernel support and an option to passed to mount! – X-Istence Mar 10 '09 at 12:00

score 0 · Answer 4 · answered Mar 09 '09 at 20:25

0

The SUID bit states that, on execution of a file (when executable), the process will run under the identity of the owner of said file, not the user that executed it.

There are a few cases where a utility program is 'suid root' to allow privilege escalation.

EDIT: Misread original question (which refers to directories rather than files) - leaving answer unaltered for educational purposes ;-)

answered Mar 09 '09 at 20:25

Jan Jungnickel

2,084
14
13

And you can't execute directories - so what would it mean applied to directories? – Jonathan Leffler Mar 09 '09 at 20:27
D'oh, you're right, I overlooked the directory part. See John Ellinwood's answer. – Jan Jungnickel Mar 09 '09 at 20:29

Does any Unix-like system ascribe meaning to the SUID bit on a directory?

4 Answers4