Bug 74

Summary:	group-wise permission not updated w/ change in group membership
Product:	Sudo	Reporter:	huffcr
Component:	Sudo	Assignee:	Todd C. Miller <Todd.Miller>
Status:	RESOLVED INVALID
Severity:	security
Priority:	normal
Version:	1.6.3
Hardware:	Sun
OS:	Solaris 2.x

Description huffcr 2002-03-15 09:55:15 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+.)

Comment 1 Todd C. Miller 2002-03-15 09:58:59 MST

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.

Comment 2 Todd C. Miller 2003-03-22 15:03:53 MST

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.