任何类Unix系统是否都意味着目录上的SUID位?

时间:2022-06-23 12:59:03

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?

正如标题所说,任何类似Unix的系统都会对目录中的SUID位赋予意义,如果是这样,它意味着什么?

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.

SVTX(保存的文本或粘滞)位有一个含义 - 除非您可以写入该文件,否则不能从该目录中删除文件。例如,它用在/ tmp上。

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

SGID(设置GID)位具有含义 - 在此目录中创建的文件应属于拥有该目录的组(尽管稍后可通过显式调用chown(2)来更改该分配)。

What about the SUID bit?

SUID位怎么样?

4 个解决方案

#1


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

作为Node的回答的后续内容,我将在FreeBSD man页面中发布以下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:

和chmod(2)手册页部分引用了suid位:

           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.

请注意,这是一个安全风险,并且在启用它时知道你在做什么,在FreeBSD中,但我相信Linux也需要启用特殊的mount标志,并且会改变该目录中文件的行为方式。

#2


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.

在大多数系统上,如果设置了目录的set-group-ID位,则新创建的子文件将继承与该目录相同的组,并且新创建的子目录将继承父目录的set-group-ID位。在少数系统上,目录的set-user-ID位对新子文件的所有权和新子目录的set-user-ID位具有类似的影响。通过减少使用chmod或chown共享新文件的需要,这些机制使用户可以更轻松地共享文件。

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.

这些便利机制依赖于目录的set-user-ID和set-group-ID位。如果像chmod和mkdir这样的命令经常清除目录上的这些位,那么机制将不太方便,并且共享文件会更加困难。因此,像chmod这样的命令不会影响目录的set-user-ID或set-group-ID位,除非用户在符号模式下特别提及它们,或者将它们设置为数字模式。

#3


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)

在目录上设置时,无论是谁创建文件,在此目录中创建的所有文件和目录都将具有与SUID目录本身相同的所有者。这是一个不经常使用的功能,但在某些情况下它可能很有用。 (资源)

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

更新:我刚试过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.

它没有效果。

#4


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.

SUID位表明,在执行文件时(可执行时),进程将以所述文件的所有者的身份运行,而不是执行该文件的用户。

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

在某些情况下,实用程序是“suid root”以允许权限提升。

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

编辑:误读原始问题(指的是目录而不是文件) - 为教育目的留下答案不变;-)

#1


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

作为Node的回答的后续内容,我将在FreeBSD man页面中发布以下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:

和chmod(2)手册页部分引用了suid位:

           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.

请注意,这是一个安全风险,并且在启用它时知道你在做什么,在FreeBSD中,但我相信Linux也需要启用特殊的mount标志,并且会改变该目录中文件的行为方式。

#2


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.

在大多数系统上,如果设置了目录的set-group-ID位,则新创建的子文件将继承与该目录相同的组,并且新创建的子目录将继承父目录的set-group-ID位。在少数系统上,目录的set-user-ID位对新子文件的所有权和新子目录的set-user-ID位具有类似的影响。通过减少使用chmod或chown共享新文件的需要,这些机制使用户可以更轻松地共享文件。

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.

这些便利机制依赖于目录的set-user-ID和set-group-ID位。如果像chmod和mkdir这样的命令经常清除目录上的这些位,那么机制将不太方便,并且共享文件会更加困难。因此,像chmod这样的命令不会影响目录的set-user-ID或set-group-ID位,除非用户在符号模式下特别提及它们,或者将它们设置为数字模式。

#3


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)

在目录上设置时,无论是谁创建文件,在此目录中创建的所有文件和目录都将具有与SUID目录本身相同的所有者。这是一个不经常使用的功能,但在某些情况下它可能很有用。 (资源)

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

更新:我刚试过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.

它没有效果。

#4


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.

SUID位表明,在执行文件时(可执行时),进程将以所述文件的所有者的身份运行,而不是执行该文件的用户。

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

在某些情况下,实用程序是“suid root”以允许权限提升。

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

编辑:误读原始问题(指的是目录而不是文件) - 为教育目的留下答案不变;-)