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?
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 #1The 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".
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 #2So 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.
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.
/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 08:38
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).
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
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 00:17
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 00:46
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.
