Right now, /bin/login is the only program which reads and sets process group permissions based on /etc/groups. It runs as root (setuid root). Only root processes can set process group memberships. In addition, the kernel currently knows nothing special about /etc/groups, and the utilities running on top of the kernel are free to implement group permission schemes as necessary (such as /bin/login using a mysql database to hold user and group data instead of /etc/passwd and /etc/groups, or remote login tables, etc).
To change it so that group membership is checked when you run a command would require a lot of changes:
1. User processes are able to change their group memberships, rather than only root processes, or, alternatively, /bin/{sh,bash,zsh,csh,...} would have to run as root. Either way would basically trash security.
2. Or the kernel would have to check /etc/groups with every process creation, which would be both slow and would prevent the use of group registration other than /etc/groups. Sure, the kernel would quickly cache /etc/groups, but it would still slow everything down. Processes are quick and cheap in unixoid systems, so it's standard to spawn them as necessary to do stuff.
3. Or /bin/{sh,bash,csh,zsh,...} would have to be modified to bounce command execution through a special setuid root program whose sole purpose is to set up group permissions. Other applications which can run commands (like, say, /usr/bin/vim or /usr/bin/gcc) would either have to be modified to use this bounce command, modified to use a shell to run commands instead of running them directly, or keep the group permission semantics which currently exist (which would be inconsistent and surprising in its own right).
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2014-04-17 02:06 pm (UTC)To change it so that group membership is checked when you run a command would require a lot of changes:
1. User processes are able to change their group memberships, rather than only root processes, or, alternatively, /bin/{sh,bash,zsh,csh,...} would have to run as root. Either way would basically trash security.
2. Or the kernel would have to check /etc/groups with every process creation, which would be both slow and would prevent the use of group registration other than /etc/groups. Sure, the kernel would quickly cache /etc/groups, but it would still slow everything down. Processes are quick and cheap in unixoid systems, so it's standard to spawn them as necessary to do stuff.
3. Or /bin/{sh,bash,csh,zsh,...} would have to be modified to bounce command execution through a special setuid root program whose sole purpose is to set up group permissions. Other applications which can run commands (like, say, /usr/bin/vim or /usr/bin/gcc) would either have to be modified to use this bounce command, modified to use a shell to run commands instead of running them directly, or keep the group permission semantics which currently exist (which would be inconsistent and surprising in its own right).