Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • This is why README should say
    perl Makefile.PL
    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?

    # 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
              sudo make
              /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 []:

    # 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");