6

Reading mod_wsgi's documentation I found you can choose which group to run the worker processes as.

I can understand group ownership of files and how only a user who belongs to that group can achieve the group permissions of that file, but I don't understand how this applies to running processes.

So, what is a process GID and what purpose does it serve?

  • When apache reads your script and executes it, it is a process, which is run by a certain user and group. These user and group determine, whether apache is allowed to read your script or not. When you manually try to execute a script from bash, it is bash process user and group, what determines, if you're allowed or not to run the script. Bash is just a process run under your user and group. So, the ownership terms are applied to processes, when they are trying to access files. – Boris Burkov May 21 '13 at 23:38
7

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

  • After reading this and checking glibc documentation I extract this conclusions: 1) Only root can change the group list of a process. Regular users can't break from the group list defined in /etc/group and they cannot i.e. remove them from a group. 2) EGID is the default group files are created by that process as. For the rest of tasks, all group permissions take the same importance, including that of EGID. – Alicia May 22 '13 at 8:38
  • @ntrrgc - Correct: 1. users can only promote one of their supplementary groups to primary status for a given process. 2. Users cannot remove themselves from a group. 3. You're comment in #2 is dead on for EGID. – slm May 22 '13 at 13:13
  • How are group permissions actually used to determine when disk access is allowed in Unix? Does unix ask question 1: "does the UID associated with this process have user permission to do this / does the UID associated with this process belong to any group that has group access to do this?" ...or... does unix ask question 2: "does the uid associated with this process have permission to do this / does the gid associated with this process have group-permission to do this?" – 8one6 Dec 4 '14 at 18:07
  • @8one6 - that's a new question, ask it and myself or others can attempt to answer it. Be sure to reference this Q so others know what you're asking about specifically. – slm Dec 4 '14 at 19:57
  • I just posted it here: unix.stackexchange.com/questions/171504/… but with a specific context in mind. If you're able to have a look, your thoughts would be much appreciated. – 8one6 Dec 4 '14 at 23:06
1

Users don't access files (they only type and move and click the mouse). Only processes can access files. The user starts a process and this process has the rights which are associated with that user (including its primary group and its supplementary groups).

  • Yes, I understand this. But if I am a user named ntrrgc who belongs to groups ntrrgc, www and ftp, if I run a process as me with group ntrrgc, it can read (AFAIK) all files readable by www and ftp groups. How is this different if I ran the process as the www process, i.e.? – Alicia May 21 '13 at 23:56
  • @ntrrgc If www is made the primary group of a process then all files, directories (and so on) which the process creates have www as their group (unless this is overwritten by the SGID bit of the parent directory). If www is the only group this process belongs to then it probably has access to fewer objects. – Hauke Laging May 22 '13 at 0:17
  • So a process may belong to several groups and have a primary one, just like users do? Can this groups be different than the ones of the user who launched it? Where can I find documentation about this matter? – Alicia May 22 '13 at 0:21
  • @ntrrgc See ps -e -o pid,group,supgrp,args and man sudo (search for "groups"). In order to start a process with groups you don't belong to you must be the superuser (at least indirectly via sudo or similar). – Hauke Laging May 22 '13 at 0:46
1

A process's permissions is based on attributes of the process. It is not directly based on entries in /etc/passwd and /etc/group. These files are only read when a user logs in; they determine the uid and gid(s) that the session's initial process runs under. Subsequent processes in the same session (children or more generally descendants of that initial process) inherit those uid and gid(s) (except for setuid/setgid programs).

For the most part, the gids of a process determine what files that process can access. If the process's uid is the owner of the file then the owner permissions apply; otherwise, if one of the process's gids (effective or supplementary) is the group owner of the file then the group permissions apply; otherwise the “other” permissions apply.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.