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 called wheel
Under Linux, group 0 does not have any special meaning to privilege escalation utilities such as sudo and su, 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).
It really comes down to what makes up a process in Unix. A process can come into existence in one of 2 ways. Either via the fork() function or through one of the exec() functions in C.
fork()
fork() basically just makes a copy of the current process, but assigns it a new process ID (PID). It's a child of the original process. You can see this relationship in the output of ps:
$ ps axjf
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 5255 1964 1964 ? -1 Sl 500 0:39 gnome-terminal
5255 5259 1964 1964 ? -1 S 500 0:00 \_ gnome-pty-helper
5255 18422 18422 18422 pts/1 18422 Ss+ 500 0:01 \_ bash
5255 30473 30473 30473 pts/4 30473 Ss+ 500 0:00 \_ bash
30473 782 782 30473 pts/4 30473 Sl 500 1:14 | \_ evince s.pdf
Here you can see that gnome-terminal is the parent process (PID = 5255) and that bash is it's child (PID = 18422, PPID = 5255).
NOTE: PPID = Parent Process ID.
When a process forks from its parent, it "inherits" certain things, such as copies of all the file descriptors that the parent currently has for open files and the parent's user and group IDs.
NOTE: The last 2 are what identify what file and group permissions this process will have when accessing the file system.
So if a process just inherits its user and group ID from its parent, then why isn't everything just owned by root or a single user? This is where exec() comes in.
exec() Part #1
The exec() family of functions, specifically execve(), "replace" a current process image with a new process image. The terminology "process image" is really just a file, i.e. an executable on disk. So this is how a bash script can execute a program such as /usr/bin/time.
So what about the user ID and group ID? Well to understand that let's first discuss the concept of "Persona".
Persona
At any time, each process has an effective user ID, an effective group ID, and a set of supplementary group IDs. These IDs determine the privileges of the process. They are collectively called the persona of the process, because they determine "who it is" for purposes of access control.
exec() Part #2
So in addition to being able to swap out the "process image", exec() can also change the user & group IDs from the original "real" ones to "effective" ones.
An example
For this demonstration I'm going to show you what happens when we start out in a shell as our default UID/GID, and then spawn a child shell using one of my supplementary GIDs, making it the child shell's effective GID.
To perform this I'm going to make use of the unix command newgrp. newgrp allows you to spawn a new shell passing it the supplementary group that I'd like to make my effective GID.
For starters:
$ id -a
uid=500(saml) gid=501(saml) groups=501(saml),502(vboxusers),503(jupiter)
We can see that this shell is currently configured with my default UID/GID of saml & saml. Touching some files shows that this is the case as well:
$ touch afile1
$ touch afile2
$ ls -l
total 0
-rw-rw-r-- 1 saml saml 0 May 21 23:47 afile1
-rw-rw-r-- 1 saml saml 0 May 21 23:47 afile2
Now we make our supplementary group jupiter the effective GID:
$ newgrp jupiter
$ id -a
uid=500(saml) gid=503(jupiter) groups=501(saml),502(vboxusers),503(jupiter)
Now if we touch some files:
$ touch afile3
$ touch afile4
$ ls -l
total 0
-rw-rw-r-- 1 saml saml 0 May 21 23:47 afile1
-rw-rw-r-- 1 saml saml 0 May 21 23:47 afile2
-rw-r--r-- 1 saml jupiter 0 May 21 23:49 afile3
-rw-r--r-- 1 saml jupiter 0 May 21 23:49 afile4
We see that the shell's effective GID is jupiter, so any interactions with the disk result in files being created with jupiter rather than my normal default group of saml.
References
Best Answer
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
passwdcommand 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 (usuallyroot), and a SETGID binary will be executed with the group privileges of the group owner of the executable file. In the case of thepasswdcommand, which belongs torootand 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 otherSETUIDcommands on UNIX-like systems (chsh,screen,ping,su, etc), all of which require elevated privileges to operate correctly. There are also a fewSETGIDprograms, where the kernel temporarily changes the GID of the process, to allow access to logfiles, etc.sendmailis such a utility.The
sticky bitserves 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/tmpdirectory. 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,/tmphas 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.