Sudo and supplemental group memberships

TJ Saunders tj at
Thu Nov 15 14:47:46 EST 2001

Todd.M>Because root can already do anything.  The only exception to this
Todd.M>is NFS with root mapped to uid -2.

The case which I encountered was the starting of a daemon that played
privilege games, setting the EUID of the process to some non-root UID.  In
the course of the running of the daemon, a file needed to be accessed.
That file was inaccessible to the EUID of the daemon.  Now, when I started
the daemon, using sudo from my account, the daemon could access that file
just fine, because sudo had initialized the process to my account's
supplemental group membership, transmitted it to the daemon process -- and
the necessary group membership for accessing the file were present.

Another sysadmin stopped, then started that daemon later, from user root's
account.  The daemon stopped functioning because it could not access the
file anymore -- the necessary group membership was no longer present.

Yes, one can argue that the permissions and/or ownership of the
troublesome file simply needed to be changed.  Yes, one can argue that the
daemon code needs to be changed.  And I agree with both.  I also think,
though, the sudo's behavior with regard to making a hard-coded exception
with regard to user root and initgroups() would be better manifested as a
command-line option, and thus a policy decision on the part of the user,
rather than an implementation decision.

Just my $0.02, of course...



   Come away, O human child!
   to the waters and the wild
   with a faery, hand in hand,
   for the world's more full of weeping
   than you can understand...

   	-William Butler Yeats


More information about the sudo-workers mailing list