Bugzilla – Bug 74
group-wise permission not updated w/ change in group membership
Last modified: 2003-03-22 19:03:53 MST
User removed from group list in /etc/group after executing command that is allowed only to members of the group can still execute the command via sudo. Resetting the datestamp of /var/run/sudo/<ex-member> to cause timestame expiration doesn't stop this behavior. Neither does deleting the directory /var/run/sudo/<ex-member>. I didn't have to do anything besides add the user to the group entry in /etc/group to enable use of the command, as I expected from the documentation. The reverse apparently isn't true. I think that simply removing the user from the group entry should prevent future access to the command without further action and do so as soon as the file /etc/group is changed. (FWIW, this system is not running NIS or NIS+.)
That doesn't make any sense. There must be another entry in sudoers granting the user privileges as well. You can run 'sudo -l' as that user to see what sudo will let them run. This may help finding what sudoers entry is allowing the user to run commands.
Removing someone from the group file doesn't change the fact that users currently logged in will still have that gid in their group vector. However, sudo doesn't directly look at the user's group vector. Instead, it relies on the getgrnam() library function which accesses the group database. Note, however, that if the group file is accessed via NIS or NIS+ that changes may not take effect immediately. Also, nscd, the name service cache daemom, may also add some latency to /etc/group changes.