Re^4: setuid script won't behave in 5.10, but did in 5.8

[isidore]

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.

[Corion]

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.

[Anonymous Monk]

Probably on the perl5-porters list, thats where everything happens

[isidore]

I found some hints in that list, thanks!

The perlsec page does mention the deprecation of suidperl deep down at the bottom. I have the impression that the construct

($>, $<) = ($<, $>)

is still supported, it's just that the package suidperl won't be.

It also suggests a solution to the deprecation of suidperl - so it seems my life has been saved :))).

Thanks to those who responded.

[Anonymous Monk]

I've just tried perl 5.10.1 as supplied with the Ubuntu 10.04 pre-release, and IT IS STILL BROKEN :-(((((

Because of this I will now have a large chunk of urgent unplanned work to find and implement an alternative to the elegant approach I had using suid.

1000 years purgatory to all programmers who think that the presence of a test package releases them from the need to think about what they are doing.