Front page | perl.perl5.porters |
Postings from December 2008
Re: suidperl goes
From: Nicholas Clark
December 23, 2008 03:02
Re: suidperl goes
Message ID: 20081223110157.GA15435@plum.flirble.org
On Tue, Dec 23, 2008 at 02:24:40PM +1100, Paul Fenwick wrote:
> G'day Nicholas / p5p,
> Executive summary: Happy for suidperl to go.
> Nicholas Clark wrote:
> > suidperl goes in 5.12
> suidperl exists as a user-space solution for what is fundamentally an OS
> problem. By indicating that a script should use suidperl, the perl binary
> itself can check to see if any trickery is involved, and then can run the
> program with additional privileges. Unfortunately, there are a lot of
> things that can go wrong, and suidperl needs to get all of them or we have
> very serious security flaws.
> The alternative to suidperl is a simple C wrapper, which is compiled and
> marked as setuid, and which simply executes perl with a filename in a known
> location (ie, not some symlink trickery). It's simple, it's easy, it's
> safe, and I could probably turn the entire thing into a command line tool.
> Having said all of that, I could be completely misjudging the situation
> here, so any picking holes in my thinking is greatly appreciated.
My impression was that any task you can currently secure with suidperl you
could rewrite to secure with sudo. sudo already exists, is well supported,
is well understood, and is maintained by people who understand what they
are doing, and aren't us. I'd prefer to recommend a migration to something
with a track record of existing, to give confidence that it will continue
to exist into the foreseeable future. I don't want "us" to create something
because we feel we should, and then create another thing that "we" need to
maintain, even if it is decoupled from core on CPAN.
A conversation with Tom in the kitchen here came up with a good summary of
the problem - "if it's in the core distribution, people assume that it's
supported, and hence use it".
We've just demonstrated that we're already not in a good position to support
this, and going forwards I'd like to reduce the maintenance burden as much
as practical, hence why I'm looking to take active steps to reduce the amount
of things that people might mistake as being supported or recommended.
Hence why anything non-core in core should go, even if it seems to be benign
and stable and not needing much care and attention right now. Just by being
there it increases the amount of stuff we have to think about. And our
thinking ability is finite.