Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Sunday October 14, 2007
08:02 PM

ALERT - File::Remove reported to "rm -rf /" during tests

[ #34680 ]

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.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

ALERT - File::Remove reported to "rm -rf /" during tests 12 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • This is why README should say
    perl Makefile.PL
    make
    make test
    sudo make install
    to discourage building (or doing anything not required) as root. (Adam's modules don't say make install in README, so it can't be blamed for someone making this module as root but ...)

    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?

    --
    Bill
    # I had a sig when sigs were cool
    use Sig;
  • Nobody installs modules by hand, they pretty much always install them via the CPAN shell.

    And thus, "sudo cpan" is probably far more common than the alternative.
    • 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...
      • 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.
    • 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.
      • 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.
    • 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.
    • 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.

      • 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.
        • 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'?

  • From Acme::BadExample [cpan.org]:

    # 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");
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.