What is it that makes new group membership require a new login (or new login shell as started by su or newgrp) to be visible?

Just running another bash (or whatever other shell) instance with --login doesn't work, but something which is suid root like su or newgrp works.

Is something inherited from the parent shell or cached which hides new group memberships?

1 Answer 1


When a child process is created, process user id and group ids are inherited from his parent process.

So when you change your user's groups (actually change config files somewhere on the disk) processes won't automatically notice it and change their group ids (non-root processes don't have rights for that anyway).

And when you start bash... well, you just start bash, nothing special happens. It just inherits parent's (graphical shell or another bash maybe) group ids.

But when you run su or login then all the magic happens. They check if you are allowed to login and change their user id and group ids (using system calls which require effective root id by the way - that's why they have suid bit set) so that all their child processes inherit these ids.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .