User's PERL5LIB env var affects sudo apt, sudo dpkg behaviour

[D J Gardner]

I think this is a bug of both sudo and dpkg. See below for my rationale.

RESULT OF ERROR:
In the middle of recovering from a crashed upgrade (xenial to bionic) I had a lot of errors of the type below:

Setting up update-inetd (4.44) ...
ListUtil.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xde00080)
dpkg: error processing package update-inetd (--configure):
 installed update-inetd package post-installation script subprocess returned error exit status 1
Setting up keyboard-configuration (1.178ubuntu2.9) ...
ListUtil.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xde00080)

CAUSE OF ERROR:
Eventually I was able to track this down to the fact that (a) I started my shell using sudo -s
(b) my PERL5LIB contained some libraries I'd manually compiled in previous years, (probably as a side-effect of cpan deciding to not use system packages if there are updated ones available) and
(c) sudo -s read my personal .bashrc, setting PERL5LIB, and this environment variable made its way past apt, etc. all the way down to dpkg --configure

BACKGROUND:
I was using apt, etc. manually because update-manager froze half way through installing (cause unknown), and I had to use reptyr to reattach the pty to a separate terminal to allow the dpkg command to run to completion, and then manually run dpkh --configure / apt install -f to
avoid having a semi-installed system.

STEPS TO REPRODUCE:
1. Have shared ListUtil library in PERL5LIB path from an incompatible perl version
2. $ sudo -s
3. # dpkg --configure packagename
Result: breaks on packages that trigger the appropriate perl module.

CONCLUSION:

I do not believe that apt and dpkg should be allowing a generic PERL5LIB environment variable to affect package installation at all, and see this as a vulnerability in the package manager as it could result in untrusted / marginally trusted / development or even malicious code being unexpectedly run with root privs.
dpkg should almost certainly strip/ignore PERL5LIB from its environment, and insist any modification of environment vars comes via (root-owned!) config files.

I also believe that sudo -s should not be using the user's .basrc, but root's