Bugzilla – Bug 133
Runas_Alias matches user and UID as text, not numerically
Last modified: 2004-03-27 08:06:44 MST
Running sudo 1.6.7p5 on Fedora Core 1 but this also seems to affect other OS such as FreeBSD 4.9. If a username is put in a Runas_Alias, the matching with the -u option is done as text. This allows a user to circumvent Runas_Alias restrictions in the sudoers file. For instance, given: Runas_Alias RUNNER=ALL, !root $ sudo -u root id Sorry, user julian is not allowed to execute '/usr/bin/id' as root on taurus.cesta.com. This is as expected. However, $ sudo -u '#0' id uid=0(root) gid=0(root) groups=0(root) If instead you restrict the run-as user based on the UID instead of the username: Runas_Alias RUNNER=ALL, !#0 then you get: $ sudo -u root id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) $ sudo -u '#0' id Sorry, user julian is not allowed to execute '/usr/bin/id' as #0 on taurus.cesta.com. This doesn't seem to be doing the right thing. If I restrict what can be done based on the UID, it ought to restrict any account that has that UID (e.g., specifying #0 ought to block root, toor, or any other account whose UID is 0). (The comparison should be done numerically so that #0 is the same as #00 or #000.) Also, even if the user is specified as text (e.g., root rather than #0), sudo ought to convert the username to a UID internally for comparison with the user specified in the -u option. Thus, specifying !root ought to block root, toor, or #0. One last thing: in the above sudo is calling initgroups() with the user specified in the -u option, which means that sudo -u root gets all of the groups that root is in, whereas sudo -u #0 gets only the default group from the password file. Perhaps sudo should call getpwuid() to convert the UID to a username before calling initgroups().
The next version of sudo will check pw_uid for the specified -u user so a !#0 in sudoers will match root, toor, #0, etc. However, specifying root in sudoers will not match other usernames with the same uid; looking up each username in sudoers in the passwd file would be too expensive. The initgroups issue has already been fixed in the sudo cvs tree.
Great, looking forward to the next release! Thanks. One last note. Regarding the decision not to lookup UIDs in the sudoers file due to cost, I agree it makes sense from an implementation point of view. Perhaps it can be revisited later if there is ever a compiled sudoers file where the UIDs have been cached (of course, this would its own concerns about when to invalidate the cache and so on).