|Do you know where your variables are?|
Re^2: Distro Pkg-Managed, broken Install.pm, sudo clears $PERL5LIB (sudoers)by martin (Pilgrim)
|on Sep 29, 2010 at 19:46 UTC||Need Help??|
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.