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).
no subject
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).