A developer was removed from the 'developers' group but still needs to run commands that require membership in that group. The user has logged out and back in, but the issue persists. What is the most likely cause?
Trap 1: The user's primary group is different from the 'developers' group.
Primary group mismatch does not prevent supplementary group access after re-login.
Trap 2: The user is using 'newgrp developers' but is no longer a member.
Using 'newgrp' without being a member will fail, but the issue is that the user hasn't refreshed their session properly.
Trap 3: The 'id' command shows the old group because the user's shell is…
'id' reads from kernel; after re-login, it should show updated groups.
- A
The user did not explicitly start a new login shell after group removal.
Group membership changes require a new login session; logging out and back in should suffice, but if the user only logged out of the desktop and the session manager cached credentials, it might not refresh. The most likely cause is that the user's current shell environment still has cached group membership from the previous session.
- B
The user's primary group is different from the 'developers' group.
Why wrong: Primary group mismatch does not prevent supplementary group access after re-login.
- C
The user is using 'newgrp developers' but is no longer a member.
Why wrong: Using 'newgrp' without being a member will fail, but the issue is that the user hasn't refreshed their session properly.
- D
The 'id' command shows the old group because the user's shell is still running.
Why wrong: 'id' reads from kernel; after re-login, it should show updated groups.