Here’s a bit of fun that kept me confused for months!
cpan is a useful little tool for downloading and installing Perl modules from cpan.org. In my work I often reach out for Perl modules, and I frequently use cpan to install them.
On one particular machine, though, cpan appeared to be broken. This machine sits behind a firewall/NAT, but big deal, they all do. I would say sudo cpan -i NewModule and cpan would hang endlessly, retrying various flavors of FTP until finally it would download its indexes, etc, over HTTP. Very annoying, because I could use wget and FTP exactly the same files in seconds from the command line.
Google around for this problem, and the answer is obvious. The firewall meant I needed to use passive FTP. Wait, not so obvious. I did export FTP_PASSIVE=1, and cpan was still unable to FTP. I also spent a while setting ftp_passive flags in various cpan config hidey holes, but in the end they didn’t do anything.
This finally dawned on me last week: I said sudo cpan -i NewModule. sudo, bless its pointy little head, tries to make the root environment more secure by filtering out environment variables! I checked, and yes indeed sudo had filtered out FTP_PASSIVE. I was busy flipping a switch on and sudo was sitting right next to me, turning it off!
The fix is laughably easy: in /etc/sudoers, look for the line with env_keep, and change it to read:
env_keep="... FTP_PASSIVE ..."
Now you can say export FTP_PASSIVE=1 in your .profile or wherever, and sudo cpan will actually see that setting. I suppose it’s possible that there’s some clever privilege escalation attack that uses FTP_PASSIVE sneaking through sudo, if your site is super-secure, you might want to look into this.
a) Use HTTP not FTP, you get resume of downloads and stuff
b) Don’t run cpan as root… http://www.nntp.perl.org/group/perl.qa/2007/10/msg9430.html
(you can do all that when you first config it when it prompts you, but I bet you have a working one)
a) Do you have a link for convincing CPAN *not* to start with 6 different flavors of FTP before zippily HTTP’ing the download? Because that was of course where I started, and I was unable to convince CPAN to adjust its heuristics.
b) Interesting link. So the argument is, that I trust your code to run in my production infrastructure and handle my data, but I don’t trust your build process? Sure, every hole you close is a good thing, but in the big picture the vulnerabilities are not reduced. In some environments I’m working in now, far more harm could come from user apache mishandling the confidential data than from user root spewing over the system config and forcing us to fail over to the backup node.