What is the case of "a process running with extra privileges process can draw upon"?

Question

From https://unix.stackexchange.com/a/18290/674

The kernel view

Conceptually, there are three sets of groups that a process is a member of. Each set is a subset of the following one.

1. The single group that is the process's default group, which files created by this process will belong to.
2. The set of groups that are checked when the group requires permission to open a file.
3. The set of groups that a process running with extra privileges process can draw upon.

For historical reasons, these sets are respectively:

1. the effective group ID (egid);
2. the effective group ID plus the supplementary group IDs;
3. all of the above plus the real group ID and the saved set-group-ID.

Questions:

1. What is the case of "a process running with extra privileges process can draw upon" in point 3?

   Is this case different from the case of "when the group requires permission to open a file" in point 2?

2. Do the "supplementary group IDs" include the primary group ID, in general and in point 2 respectively?

   By "in general", I mean that I notice the output of id includes both primary and supplementary groups following groups=, while https://unix.stackexchange.com/a/18203/674 says "each user can belong to a number of supplementary groups - and these are listed at the end of id output." So I wonder if the primary group is also a supplementary group?

Thanks.

Answer 1

1. In Linux specifically, nowadays, a “process running with extra privileges process can draw upon” is a process which “has the CAP_SETGID capability in its user namespace”.

   Note that the introduction of the three points states that “each set is a subset of the following one”, so yes, the set described in point 3 is different, conceptually, from the set described in point 2.

2. id prints the effective group, not the primary group; you can change your effective group using newgrp. The primary group is the default real/effective group. On Linux, getgroups’ manpage mentions that “it is unspecified whether the effective group ID of the calling process is included in the returned list”, so the supplementary groups don’t necessarily include the primary group.

Still considering Linux specifically, it’s worth reading the credentials manpage.

Answer 2

Given the number of different concepts, I find them easier to learn through practical examples.

Programs like the userspace NFS server, act on behalf of a specific user connected over the network. They temporarily change their effective user and group ids e.g. when opening a file on behalf of a specific user. They are able to switch back, because they still have the privileged UID and GID in either their "saved-set" or "real" UID and GID.

I recently learned that fusermount is another example of a program that does this. It must be set-uid root so that it can mount filesystems, but it wants to perform permission checks as the original user e.g. when reading configuration files, and reaching the directory which is passed as a mount point. At least, it must change its UID like this. If this program was also set-gid, then it would also have to change its GID. fusermount does not need to be installed as set-gid, but the code changes its effective GID anyway. It doesn't take much more code, and at least I hope it doesn't cause any problems :-).

The man page for setfsgid() mentions this example when it says

Explicit calls to setfsuid() and setfsgid() are usually used only by programs such as the Linux NFS server that need to change what user and group ID is used for file access without a corresponding change in the real and effective user and group IDs

[...]

The filesystem user ID attribute was added to allow a process to change its user ID for the purposes of file permis‐ sion checking without at the same time becoming vulnerable to receiving unwanted signals. Since Linux 2.0, signal permission handling is dif‐ ferent (see kill(2)), with the result that a process change can change its effective user ID without being vulnerable to receiving signals from unwanted processes. Thus, setfsuid() is nowadays unneeded and should be avoided in new applications (likewise for setfsgid(2)).

i.e. current versions of these programs will temporarily change their effective UID and GID, using setresuid() and setresgid().