Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

samtregar (2699)

samtregar
  (email not shown publicly)
http://sam.tregar.com/

Journal of samtregar (2699)

Thursday March 23, 2006
05:39 PM

Why your code might break on Fedora Core 5

[ #29085 ]
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:

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.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Why your code might break on Fedora Core 5 7 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • IIRC PERL5LIB and the like are always stripped out, and you can't disable this, for obvious security reasons.
    • 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

      • 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?

          -sam

  • 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 [gratisoft.us] file.
    Defaults env_reset
    Defaults env_keep="MYVAR MYOTHERVAR"
    That makes it pretty explicit what's required.

    -Dom

  • 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'.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.