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

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?

From stackoverflow

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

  Jonathan Leffler : And you can't execute directories - so what would it mean applied to directories?

  Jan Jungnickel : D'oh, you're right, I overlooked the directory part. See John Ellinwood's answer.

• 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.

  Jonathan Leffler : Do you know of any systems which actually support it - the URL says it happens, but I'm not clear on which platforms.

  John Ellinwood : Edited my post. Looks like it works on OpenSuSE 11.0

  Martin Carpenter : @John: You've demonstrated SGID on directory, not SUID. Solaris and Linux support SGID on directories out of the box.

  John Ellinwood : 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.

  X-Istence : SGID works on FreeBSD too, SUID however requires kernel support and an option to passed to mount!

• 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.

  Jonathan Leffler : 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?

  Node : 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.

• 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.

  Jonathan Leffler : 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.

  Node : 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*

  X-Istence : @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.

  Martin Carpenter : 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.

  X-Istence : @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!