Why your code might break on Fedora Core 5

I'm sure there are other reasons, but this one struck me as rather aggregious:

$ export FOO=bar $ echo $FOO bar $ sudo bash -c 'echo $FOO'

$

That's right, sudo no longer passes through environment variables by default. I don't know about you, but this seems quite likely to bite lots of code I write. I often do environment setup (PERL5LIB, PATH, directory roots, etc) and then run a sub-process as another user via sudo. I'm expecting a flood of reports of problems from DBD::Oracle users as they find that ORA_HOME mysteriously stopped working when the upgrade to FC5.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

As far as doing this for "security reasons", meh. Giving a user sudo access is just asking for a security elevation attack. Making it a little harder by restricting environment vars isn't buying all that much.

I strongly disagree with that. sudo 1.6.8p12 blocks PERL5LIB and PERL5OPT (and ENV, BASH_ENV, SHELLOPTS, etc., see env.c in the sources.) If you don't do that, you can't give sudo access to any program written in perl without the risk of it loading untrusted code (e.g. via PERL5OPT=-MNasty::Module), even if this Perl program is a very simple, taint-checked and carefully crafted script.

You strongly disagree with what exactly? My statement was a statement of fact regarding Fedora Core 3 and whatever version of sudo is running there (I'd check but I'm on a Windows box at the moment). I think I've demonstrated that what I said was true. Is there something wrong with the way I'm testing perhaps?

Now I understand why running sudo perl -MCPAN -e shell would end up with root owned files in my normal user home directory. And it also accounts for gpg problems with Module::Signature (~/.gpg/ owned by someone else). Basically after sudo everything still thinks $HOME is the normal user's directory not ~root/.

Actually it's related but slightly different. If you want $HOME to be set to the target user's home directory (rather than passing throught the calling user's $HOME) then you want to use either the 'set_home' or 'always_set_home' options described in 'man sudoers'.