All the Perl that's Practical to Extract and Report

Why your code might break on Fedora Core 5

samtregar on 2006-03-23T22:39:41

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 fix is easy, just undo the change discussed here:

http://www.redhat.com/archives/fedora-devel-list/2006-February/msg00382.html

I like Josh Bresser's comment about this change:

as long as there is a release note about it, it will only surprise the people who don't read the release notes

I guess that's true. Only problem is, it wasn't put in the release notes!

-sam

PS: Shout out to Michael Peters for tracking this one down.

PERL5LIB

rafael on 2006-03-23T22:50:35

IIRC PERL5LIB and the like are always stripped out, and you can't disable this, for obvious security reasons.

Re:PERL5LIB

samtregar on 2006-03-23T22:58:58

Well, not on FC3, thank god:

   $ export PERL5LIB=foo
   $ sudo bash -c 'echo $PERL5LIB'
   foo

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.

-sam

Re:PERL5LIB

rafael on 2006-03-24T08:19:27

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.

Re:PERL5LIB

samtregar on 2006-03-24T08:38:37

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?

-sam

Debian Security Upgrade

Dom2 on 2006-03-23T23:15:38

A Debian Security Upgrade made this change for us. It turns out that the easiest way to get around this is to define the correct behaviour in the sudoers file.
Defaults env_reset
Defaults env_keep="MYVAR MYOTHERVAR"
That makes it pretty explicit what's required.

-Dom

Now I understand

blm on 2006-03-24T00:18:06

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/.

Re:Now I understand

grantm on 2006-03-24T00:41:09

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'.