in reply to Re: setuid script won't behave in 5.10, but did in 5.8
in thread setuid script won't behave in 5.10, but did in 5.8

Wow that was a fast reply! Thanks! The following is a challenge aimed at whoever made the deprecation decision for 5.11 (I'm not shooting the messenger):

Admittedly it needs a little more setup than most testing - the use of one extra user account, but my example script is trivial and the wrapper to demonstrate it would also be trivial. After being setup once the test script would continue to work as a regression test, and especially for a user on linux, the initial setup wouldn't take much work. Therefore it ought to be testable automatically. Since perl is heavily used by sysadmins I'd say that this feature is Important. Come on are you a perl programmer or not?
  • Comment on Re^2: setuid script won't behave in 5.10, but did in 5.8

Replies are listed 'Best First'.
Re^3: setuid script won't behave in 5.10, but did in 5.8
by Corion (Patriarch) on Mar 22, 2010 at 15:48 UTC

    Suidperl was deprecated in Perl 5.10.1 and is dead with 5.12, to be released within the next two weeks. It died because there was nobody using it and nobody spoke up in favour of it, and it introduced far too many bugs, and bugs in suidperl are usually system compromises.

    Usually, Perl testers run under one single user and hence don't test the user switching automatically. If you want to provide a patch to test user switching and the setup to change users automatically and unattended, you can submit it to perl5-porters@perl.org for inclusion with Perl.

[reply]
[d/l]
      Thanks for the information.

      That is VERY Bad News. This is going to break my perl program and probably cost me at least 2 man weeks to code up an alternative - which seems like it is now going to have to be written in another language. This is a bad day for my love affair with Perl :((((

      The message in the deprecation announcement is very cryptic - do you know where I can find more information on the subject?
      - does it mean, for example, that everything documented in the live perlsec page http://perldoc.perl.org/perlsec.html (which still starts with the very enticing sentence "Perl is designed to make it easy to program securely even when running with extra privileges, like setuid or setgid programs.") is now being stripped out of perl - why then doesn't that page warn of the deprecation?

      Similarly http://perldoc.perl.org/perlvar.html (for version 5.10.1) still happily reports in the bit about $EFFECTIVE_USER_ID that the setuid construct I mentioned at the start of this thread is still provided with no deprecation warnings to be found.

      I am also puzzled about the wording of the deprecation notice: "suidperl ... provides a mechanism to emulate setuid permission bits on systems that don't support it properly". Linux DOES support setuid properly. Everything from (e.g.) Stevens' book "Advanced Unix programming" is supported.

      Added after original post: I've just discovered what is meant: Linux doesn't fully honour setuid bits on scripts. Further the perlsec page does mention the deprecation deep down at the bottom. It also suggests a solution - so it seems my life has been saved :))).

      Thanks to those who responded.
[reply]

        It's unfortunate that the documentation wasn't patched when Perl 5.10 was released, but as it turned out that nobody had tested the suidperl functionality for 5.10, and it was broken and nobody had complained, it was deemed that there was no active interest in keeping suidperl, especially as it has been a constant source of security problems. I think the usual solution to not using suidperl is the C program documented at perlsec under "Security bugs". There you'll also find the following:

        The use of suidperl is considered deprecated, and will be removed in Perl 5.12.0. It is strongly recommended that all code uses the simplier and more secure C-wrappers described below.

        The other approach to avoiding setuid / suidperl is to have a separate daemon program that runs as root and which accepts commands through a unix domain or TCP socket or a directory into which files with commands are dropped. So it's likely that you can rework your program that way if the C wrapper from perlsec does not work out for you.

[reply]
[d/l]
        Probably on the perl5-porters list, thats where everything happens
[reply]

In Section Seekers of Perl Wisdom