Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
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'

      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?


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


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