blaisepascal: (Default)
blaisepascal ([personal profile] blaisepascal) wrote in [personal profile] marnen 2014-03-19 05:43 pm (UTC)

"group membership is read at login" is not technically correct. For these purposes, it's effectively correct, but that's not fully what's going on.

Group membership of a process can only be changed by processes with CAP_SETGID privileges -- effectively root processes only. This prevents users from setting the groups of their own processes -- and thus potentially escalating their privileges and compromising system security.

So when you login, the login program validates your password, reads /etc/groups and /etc/passwd to find out about who you are, calls setgroups() and setreuid() to set your groups and user ids, then calls execv() to start your login shell. Gdm does something similar (it might even call login behind the scenes).

But when you update /etc/groups, existing processes cannot change what groups they belong to, and cannot access the updated privileges.

This plays both ways: "usermod -a -G vboxsf marnen" doesn't add vboxsf to your current shell's groups, but neither does the equivalent editing of /etc/groups to remove you from a group.

It's the way it is for security reasons, not because programmers are lazy. "Fixing it" would require redesigning, revetting, and redeploying a whole new security model for Unixoid systems.

Post a comment in response:

This account has disabled anonymous posting.
If you don't have an account you can create one now.
HTML doesn't work in the subject.
More info about formatting