Bugzilla – Bug 268
Implicitly allow SETENV for "ALL" commands
Last modified: 2007-12-04 12:13:45 MST
Created attachment 215 [details] first shot at a patch 1.6.9 introduced the SETENV tag (thank you for switching to env_reset by default, that helped us to drop a very large patch!) However, I do not see a reason to deny SETENV to a user which can run ALL commands anyway, since he can just run /usr/bin/env with the additional variables, or run a shell script wrapper which collects the variables and shoves them to the sudo'ed command. Thus, denying SETENV for cmnd 'ALL' does not provide any security, it just causes inconvenience. I propose to implicitly allow SETENV in this case, I attach a small patch for this. Of course we could ask people to add the SETENV: tag to their sudoers, but this is not really discoverable, and automatically rewriting a sensitive configuration file like sudoers on upgrades is a no-go, too. Thank you for considering, Martin
Other people have asked for this behavior as well. I've been reluctant to do so since I'd prefer that permission be granted explicitly. Your diff would basically make ALL equivalent to SETENV:ALL and would thus be "sticky" if multiple commands are on the same sudoers line. This may not be a big deal--I'll have to give it some thought.
I've committed a similar change to cvs HEAD and the SUDO_1_6_9 branch. It will show up in the next sudo release.
I just upgraded to sudo 1.6.9p9 which has that patch according to the changelog, but I still cannot set env variables by default: $ sudo -E env sudo: sorry, you are not allowed to preserve the environment $ sudo -l User martin may run the following commands on this host: (ALL) ALL $ sudo grep -v '^#' /etc/sudoers | grep -v '^$' Defaults !lecture,tty_tickets,!fqdn root ALL=(ALL) ALL %admin ALL=(ALL) ALL (I am in group admin). Maybe this does not work for group membership? Thank you!
There was a change missing from the tarball. I've updated the tarball, please grab a fresh copy and try that.
Works like a charm. Thanks a lot!