0

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.

Community
  • 1
Tim
  • 101,790

2 Answers2

2

  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.

Stephen Kitt
  • 434,908
  • Looking at man setresuid() I think a process can be running without CAP_SETGID, but still shuffle its UIDs around if they are different, e.g. it's "real" GID may be a different group that it can switch back to. I think that's really what point 3 is trying to refer to. – sourcejedi Sep 04 '18 at 11:51
  • @sourcejedi I’m trying to think of a scenario where an unprivileged process would have different real/effective/saved gids — can you? – Stephen Kitt Sep 04 '18 at 12:10
  • "games are often (or used to be) shipped setgid to the games group so that they can write to a shared high-score table." I'm pretty sure they're not gaining CAP_SETGID :-). But I can't think of a practical example where this is taken advantage of . – sourcejedi Sep 04 '18 at 12:16
  • Ah yes, CAP_SETGID is rather more than that, oops ;-). (To be fair though I didn’t claim a link in my comment on your question — but I did in my answer.) – Stephen Kitt Sep 04 '18 at 12:20
  • Thanks. May I ask in /etc/passwd, can two lines with different user names and the same user ID have different values for the group ID field, or must they have the same value for the group ID field? – Tim Sep 04 '18 at 15:29
  • set-GID executables are a common way to provide a way through a secure only-group-executable trap-door to a world-writable submissions spool area, Stephen Kitt. Think of how mail, at, and print jobs are enqueued, for starters. This is often nowadays done with unprivileged groups rather than with set-UID. Then there are write and wall. – JdeBP Sep 05 '18 at 07:34
  • @JdeBP I know about those, funnily enough (see also my comment about games writing to shared high-score tables); my comment stemmed from confusion around CAP_SETGID. setgid binaries do fit the bill as far as the scenario being discusses goes, since they’re not privileged (by the CAP_SETGID definition) but can still switch group ids. – Stephen Kitt Sep 05 '18 at 08:13
1

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

sourcejedi
  • 50,249
  • 1
    That is “only” a subset of use-cases where extra permissions are useful — e.g. games are often (or used to be) shipped setgid to the games group so that they can write to a shared high-score table. – Stephen Kitt Sep 04 '18 at 11:43