Re: Distro Pkg-Managed, broken Install.pm, sudo clears $PERL5LIB (sudoers)

[shmem]

Not a big deal.

sudo(8) clears the environment depending on the content of the sudoers file. Consulting the sudoers(5) manual page helps.

Defaults            env_keep += "PERL5LIB PERL5OPTS"

# or even

Defaults:Intrepid   env_keep += "PERL5LIB PERL5OPTS"

in the sudoers file fixes that.

[martin]

Sudo clears the environment for a reason.

The fact that PERL5LIB can replace modules run with borrowed privileges makes it particularly important to get blocked, or control over what code will be executed is lost.

Rather than honoring whatever library settings the sudoer provides, that choice should be made on the side of the target account (root, say).

In the OP situation sudo can give the person updating site add-ons full control, which can be used then to set paths explicitly, or set up the environment with fixed settings in harmony with the local installation preferences.

But please do not make passing on PERL5LIB a default.

Btw, if perl detects being run with borrowed privileges it ignores PERL5LIB on its own account, and turns on other safety precautions, too (see perlsec). But this will not happen under sudo, as sudo sets real and effective IDs at the same time and thus hides the fact that a transfer of privileges has taken place at all.

In order to keep site add-ons visible even if running in taint mode, PERL5LIB may be not the best mechanism to depend on. Many distributions reserve file hierarchies for site and/or vendor libraries for that reason. Debian, e.g., compiles perl with /usr/local subdirectories in @INC, where distro packages never go. You could still use /opt/foobar with a symbolic link in the distro's idea of the site-specific location pointing there.

[shmem]

But please do not make passing on PERL5LIB a default.

Why? The PERL5LIB environment variable is set up after the fact (of changing $< and $>) of getting broader permissions via sudo.

So, a well thought-out privilege evelating scheme is more important than the passing of an environment variable while changing $UID, becaue you could set that very ENV var by hand, after running sudo.

That statement of yours which I quoted looks to me very much like the bogus "eval is evil" and "don't use system $string" warnings, which are nonsense as absolutes, i.e. without context.

[martin]

martin But please do not make passing on PERL5LIB a default.

shmem Why? The PERL5LIB environment variable is set up after the fact (of changing $< and $>) of getting broader permissions via sudo.

Sudo is not only used to hand out superuser shells. It is designed to give limited access to a variety of actions in a precisely controlled fashion, most notably perhaps running scripts with privileges of a different user.

This can, for instance, enforce the use of a particular interface to some system service. To that end it is mandatory that the sudoer cannot change what code is being run via environment variables such as PERL5LIB. Therefore, caution would dictate not to undermine this safety feature through careless defaults. You can always be more specific where you have to.

I find it reasonable to play safe by default. You may resolve a certain incommodity the way you suggested, but should be aware of the security implications, too.

[Crackers2]

But please do not make passing on PERL5LIB a default.

Why? The PERL5LIB environment variable is set up after the fact (of changing $< and $>) of getting broader permissions via sudo. So, a well thought-out privilege evelating scheme is more important than the passing of an environment variable while changing $UID, becaue you could set that very ENV var by hand, after running sudo.

^^^ What martin said. In a lot of cases the user making the sudo call does not control the code that is being called.

In that case, passing through PERL5LIB is like passing through PATH or LD_LIBRARY_PATH. Just google "sudo PATH exploit" to find plenty of examples of the trouble you can run into.

So yes, if you're sure that sudo is only used to give full shell access, then by all means go ahead and pass through PERL5LIB. In all other cases, leaving it out it probably a better idea.