On Sat, Dec 7, 2013 at 11:58 AM, Todd C. Miller <[email protected]> wrote: > On Sat, 07 Dec 2013 10:42:28 -0430, Andres Perera wrote: > >> Previously, the check was a string comparison of username against >> run_as_default, which is influenced, possibly among other things, by >> the compile-time configuration of RUNAS_DEFAULT This is distinct from >> an uid check. > > No, the comparison was not betwwen username and def_runas_default. > The comparison was between def_runas_default and root. > > strcmp(runas_user ? runas_user : def_runas_default, "root") != 0 > > This compares either the user specified via the -u option or, if > no -u was give on the command line, the value of runas_default in > the sudoers file. In either case the value is compared to "root". > > The intent of the check is to only allow the login class to be set > if the user running sudo is root or the user the command is being > run as is root. > > The new check is: > > user_uid != 0 && pw->pw_uid != 0 > > which preserves the intent of the check. I considered doing: > > user_uid != 0 && strcmp(pw->pw_name, "root") != 0 > > but the uid check seems better as "root" has no meaning to the > kernel, it is the uid that really matters and any command running > with uid 0 should be able to modify its resource limits.
The considerations of the kernel are irrelevant. A user to sudo, more specifically in this comparison, was an n-tuple of username, password, uid, gid, and so on. Under this definition, two users can have different user names but matching uids. The previous check permitted only "root", the new one permits any n-tuple with uid == 0. This is different behaviour, not a strict fix. > > - todd
