In the view of the latest suidperl exploit and the fact that suidperl is used only in a very rare circumstances (not by Red Hat RPMS at least :), it'd be a good idea to split it to a subpackage which wouldn't be installed by default.
Or just remove it completely. :)
How about put the new suidperl package on Powertools so that an install of "everything" in the standard distro has one less maniac suid-root program? P.S. to be awkward, severity -> security :-) P.P.S. Speaking of maniac suid-root programs why is procmail suid-root?
procmail is setuid root to do mail delivery. Putting sperl in powertools is complex merely due to our build process (having one source RPM make package X for the main distro and package Y from the powertools is not really supported at the moment.)
I think this should now be taken to reconsideration :-) The most difficult change would be listing all bindir filenames in the spec file instead of %{_bindir}/*. No need to even add perl-suidperl to RedHat/base/comps ;-)
I believe Debian has a seperate "perl-suid" package. I agree that splitting suidperl in a seperate package, not installed by default, is the only sane thing to do, besides not shipping it at all, which of course also is a solution.
This bug would be a good one to re-visit for RH7.1 final. Here is the rationale: - 7.1 beta-3 is looking _very_ secure, so eliminating some of the bigger suid-root stuff is likely to be a big win. - Hardly anyone uses suid-perl. Perhaps the following way of proceeding would keep most people happy: - Split suid-perl into a sub-package - Keep it in the main distro - Only install it if explicitly selected in the installer - i.e. its one of the magic packages omitted by an "everything" install. - also, the common install classes should _not_ contain the new package.
Chip, can you please do this for your next build?
Latest RAWHIDE perl will now split off a perl-suidperl package with one file, /usr/bin/suidperl.