How do Linux permissions work when a process is running as a specific group?

Question

This is something I haven't been able to find much info on so any help would be appreciated.

My understanding is thus. Take the following file:

-rw-r-----  1 root        adm   69524 May 21 17:31 debug.1

The user phil cannot access this file:

phil@server:/var/log$ head -n 1 debug.1
cat: debug.1: Permission denied

If phil is added to the adm group, it can:

root@server:~# adduser phil adm
Adding user `phil' to group `adm' ...
Adding user phil to group adm
Done.
phil@server:/var/log$ head -n 1 debug.1
May 21 11:23:15 server kernel: [    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014

If, however, a process is started whilst explicitly setting the user:group to phil:phil it cannot read the file. Process started like this:

nice -n 19 chroot --userspec phil:phil / sh -c "process"

If the process is started as phil:adm, it can read the file:

nice -n 19 chroot --userspec phil:adm / sh -c "process"

So the question really is:

What is special about running a process with a specific user/group combo that prevents the process being able to access files owned by supplementary groups of that user and is there any way around this?

Answer 1

A process is run with a uid ang a gid. Both have permissions assigned to them. You could call chroot with a userspec of a user and group, where actually the user is not in that group. The process would then executed with the users uid and the given groups gid.

See an example. I have a user called user, and he is in the group student:

root@host:~$ id user
uid=10298(user) gid=20002(student) groups=20002(student)

I have a file as follows:

root@host:~$ ls -l file
-rw-r----- 1 root root 9 Mai 29 13:39 file

He cannot read it:

user@host:~$ cat file
cat: file: Permission denied 

Now, I can execte the cat process in the context of the user user AND the group root. Now, the cat process has the necessary permissions:

root@host:~$ chroot --userspec user:root / sh -c "cat file"
file contents

Its interesting to see what id says:

root@host:~$ chroot --userspec user:root / sh -c "id"
uid=10298(user) gid=0(root) groups=20002(student),0(root)

Hm, but the user user is not in that group (root). Where does id get its informations from? If called without argument, id uses the system calls, getuid(), getgid() and getgroups(). So the process context of id itself is printed. That context we have altered with --userspec.

When called with an argument, id just determines the group assignments of the user:

root@host:~$ chroot --userspec user:root / sh -c "id user"
uid=10298(user) gid=20002(student) groups=20002(student)

To your question:

What is special about running a process with a specific user/group combo that prevents the process being able to access files owned by supplementary groups of that user and is there any way around this?

You can set the security process context that is needed to solve whatever task the process needs to do. Every process has a uid and gid set under which he runs. Normally the process "takes" the calling users uid and gid as his context. With "takes" I means the kernel does, otherwise it would be a security problem.

So, it's actually not the user, that has no permissions to read the file, its the process' permissions (cat). But the process runs with the uid/gid of the calling user.

So you don't have to be in a specific group for a process to run with your uid and the gid of that group.

Answer 2

Using the --userspec option on chroot specifies the user and a single group to use when running the chroot. To define supplementary groups you need to use the --groups option as well.

By default processes inherit the primary and supplementary groups of the user running them, but by using --userspec you're telling chmod to override that using the single group specified.

Detailed documentation of permissions in Linux is available in the credentials(7) manpage.

Answer 3

When you log into Linux, the login process¹ -after verifying you can log in as phil- gets the uid of phil and the groups it belongs to, setting those as a process which is then started as your shell. The uid, gid and supplemental groups are a property of the process.

Any later program started after that, is a descendant of that shell, and simply receives a copy of those credentials.* This explains why changing the rights of the user doesn't affect the running processes. The changes will be picked up on next login, however.

* The exception are programs whose setuid or setgid bits are set, which will have a different effective user id. This is used for instance in su(1) so it can run with root privileges even when executed by phil.

After you added phil to the adm group, he could run su phil, and su will -running as root- verify that he indeed provides phil's password and then land him into a shell with the uid, gid and supplemental groups phil belongs to. And as this is done after adding the user to the group, that shell would already be in the adm group.

I don't consider chroot(1) the most suited program for running as a different user, but it certainly gets the work done. The parameter --userspec phil:phil makes it run with the uid of phil and the gid of phil. No additional groups are set (for that you would provide --groups). Thus, the children process is not in the adm group.

A more normal way for running your process as phil would be su phil -c "process". As su loads the uid, gid and supplemental groups from the user database information, process will have the same credentials the user currently has.

¹ This may be login(1), sshd, su, gdb or other programs. Also, it is likely being managed through pam modules.