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?

Was it helpful?

Solution

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.

OTHER TIPS

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.

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.

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 ;-)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top