Every process in a UNIX-like system, just like every file, has an owner (the user, either real or a system "pseudo-user", such as daemon
, bin
, man
, etc) and a group owner. The group owner for a user's files is typically that user's primary group, and in a similar fashion, any processes you start are typically owned by your user ID and by your primary group ID.
Sometimes, though, it is necessary to have elevated privileges to run certain commands, but it is not desirable to give full administrative rights. For example, the passwd
command needs access to the system's shadow password file, so that it can update your password. Obviously, you don't want to give every user root privileges, just so they can reset their password - that would undoubtedly lead to chaos! Instead, there needs to be another way to temporarily grant elevated privileges to users to perform certain tasks. That is what the SETUID and SETGID bits are for. It is a way to tell the kernel to temporarily raise the user's privileges, for the duration of the marked command's execution. A SETUID binary will be executed with the privileges of the owner of the executable file (usually root
), and a SETGID binary will be executed with the group privileges of the group owner of the executable file. In the case of the passwd
command, which belongs to root
and is SETUID, it allows normal users to directly affect the contents of the password file, in a controlled and predictable manner, by executing with root privileges. There are numerous other SETUID
commands on UNIX-like systems (chsh
, screen
, ping
, su
, etc), all of which require elevated privileges to operate correctly. There are also a few SETGID
programs, where the kernel temporarily changes the GID of the process, to allow access to logfiles, etc. sendmail
is such a utility.
The sticky bit
serves a slightly different purpose. Its most common use is to ensure that only the user account that created a file may delete it. Think about the /tmp
directory. It has very liberal permissions, which allow anyone to create files there. This is good, and allows users' processes to create temporary files (screen
, ssh
, etc, keep state information in /tmp
). To protect a user's temp files, /tmp
has the sticky bit set, so that only I can delete my files, and only you can delete yours. Of course, root can do anything, but we have to hope that the sysadmin isn't deranged!
For normal files (that is, for non-executable files), there is little point in setting the SETUID/SETGID bits. SETGID on directories on some systems controls the default group owner for new files created in that directory.
Best Answer
Unlike user 0 (the root user), group 0 does not have any special privilege at the kernel level.
Traditionally, group 0 had special privileges on many unix variants — either the right to use
su
to become root (after typing the root password), or the right to become root without typing a password. Basically, the users in group 0 were the system administrators. When group 0 has special privileges, it is calledwheel
Under Linux, group 0 does not have any special meaning to privilege escalation utilities such as
sudo
andsu
, either. See Why is Debian not creating the 'wheel' group by default?Under CentOS, as far as I know, group 0 has no special significance. It is not referenced in the default
sudoers
file. The administrators on that system may have decided to emulate a unix tradition and confer members of group 0 some special permissions. Check the PAM configuration (/etc/pam.conf
,/etc/pam.d/*
) and the sudoers file (/etc/sudoers
) (these are not the only places where group 0 might have been conferred special privileges, but the most likely).