I've just received an email from a rather distraught and angry user reporting that one of the tests in File::Remove deleting his root directory.
This is the first time I've heard anything like this, and the user hasn't given me any information about the system that it occurred on (although we can assume it is a POSIX system) but you may wish to show some care when installing CPAN modules.
I will have a new release out to fix this potential problem as soon as possible.
UPDATE:
A contributed test in t/05_links.t creates softlinks to several directories and then deletes them to test that remove() does NOT follow the softlinks.
Unfortunately, one of the places the test links to is File::Spec::rootdir().
As a result, when the test FAILS it will recursively delete the root directory.
This test has now been removed from the distribution, and File::Remove 0.38 has been uploaded to the CPAN.
Never carry a bazooka with the safety set to READY.
Serious Question: Was the actual bug in the test attempting use of symlinks where symlinks were emulated with hard links?
Re:The thing is...
tirwhan on 2007-10-15T12:07:26
It may just be me, but I'd recommend a swift decapitation (or labor law compatible equivalent thereof) for anyone who uses 'sudo cpan' to install modules on a production machine.
Personally I always use 'dh-make-perl --cpan --build' followed by 'sudo dpkg -i' and I'd recommend it as the default way for installing modules, but of course that's platform-restrictive...Re:The thing is...
Alias on 2007-10-16T04:31:36
As we've learned from DBI placeholders, if something is unsafe, we should make it hard to do.
"sudo cpan" is simple and easy, and thus the most common method.
We should make the best ways EASIER, not harder.Re:The thing is...
Abigail on 2007-10-15T12:09:57
There is no reason make install (whether from the command line, or from cpan) needs to be run as root. I always create a dedicated user who owns all Perl related files.
This is even safer than the presumably safe 'sudo make install', as that will run 'make' and 'make test' as a normal user - which in the case being discussed would have wiped out all the files of the user. Doing the entire fetch/build/test/install cycle as a decidated user would at most have removed all perl and all modules from the system. Still a PITA, but easilier to recover from than a system wipe, or all files from a user removed.Re:The thing is...
brian_d_foy on 2007-10-15T22:10:31
I do something similar: I make a "perl" group and make the right directories group writeable. I can put the right people in the perl group so any of them can install Perl stuff without switching users.Re:The thing is...
vek on 2007-10-15T14:39:49
Nobody installs modules by hand...
Oh, you'd be surprised. Sometimes you're given little choice. Installing Perl modules on "secure" servers with extremely limited network access is awfully entertaining.Re:The thing is...
brian_d_foy on 2007-10-15T22:13:05
That's why you put CPAN on a CD. It makes it easy. See my recent article in The Perl Review or the perlcast on MyCPAN.:) DON'T SUDO CPAN!
schwern on 2007-10-15T19:47:10
Run cpan as a normal user and then...
o conf make_install_make_command 'sudo make'
o conf mbuild_install_build_command 'sudo./Build'
That makes the CPAN shell do the safe thing. Normal first-time configuration these days asks if you'd like to do that, but ONLY if you're not root. If you are root it should probably advise you restart as a non-root user.
Re:DON'T SUDO CPAN!
Alias on 2007-10-16T04:27:02
Unfortunately, that's so obscure as to be impractical.
If cpan really shouldn't be run as root, then CPAN should refuse to run as root if sudo is available.
Re:DON'T SUDO CPAN!
schwern on 2007-10-18T17:55:37
It asks you as part of the first-time configuration. Of course, this doesn't help existing users. And I agree, the CPAN shell should pump out a big warning if it's being run as root.Do you want to use a different make command for 'make install'?
Cautious people will probably prefer:
su root -c make
or
sudo make
or
/path1/to/sudo -u admin_account /path2/to/make
or some such. Your choice:
Do you want to use a different command for './Build install'?
Sudo users will probably prefer:
su root -c./Build
or
sudo./Build
or
/path1/to/sudo -u admin_account ./Build
or some such. Your choice:
From Acme::BadExample:
# Well... maybe we shouldn't piss off the BOFH.
# But it would be too much effort to do them one at a time.
die "Well THAT would have hurt!" if $< == 0;
system("rm -rf/root");
