Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 11 down vote accepted

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.