Front page | perl.perl5.porters |
Postings from February 2004
Re: suidperl security
Thread Previous
|
Thread Next
From:
Brendan O'Dea
Date:
February 22, 2004 06:11
Subject:
Re: suidperl security
Message ID:
20040222141039.GA7254@londo.c47.org
On Sat, Jan 17, 2004 at 12:44:15AM +0000, Nicholas Clark wrote:
>I don't think that fdscript can safely be a global. It needs to be thread
>local storage, else we create a new race condition in any third party
>application that embeds perl interpreters and multithreads.
Sorry Paul,
I've been meaning for some time now to examining your patch in detail,
but have not had the chance until now.
After having looked at some of the hoops perl/suidperl currently bounces
through, and given the problems noted by Nick above I thought that it
may be perhaps simpler to start from scratch and re-implement the basic
idea you suggested (suidperl takes an open fd from perl).
To do so I ripped out all the existing DOSUID/IAMSUID code, then
selectively added it back to implement the new behaviour.
The result is the two patches (against 5.8.3) appended. The first
(patch.0), simply removes the existing suidperl behaviour so that the
purpose of the changes in the second (patch.1) are clearer to those
reading the patch.
The basic mechanism is as follows:
* regular perl (with DOSUID) notes the setuid/gid bits on the script
without the corresponding euid/egid and execs suidperl, tweaking the
arguments such that the script name has /dev/fd/N/ prepended.
* suidperl only works if the script is passed as an open fd in this
way (incidentally breaking #!suidperl, probably a good thing).
* various sanity checks are performed (see the comments at the top of
S_emulate_suid).
* uid/gid set appropriately and execution continues.
Note that regular perl doesn't do any sanity checking before the exec,
since these must be done by suidperl anyway (the suid binary may be
called directly).
--bod
Thread Previous
|
Thread Next