develooper Front page | perl.perl5.porters | Postings from February 2011

Re: setuid and serious trouble (Re: Time to update

Thread Previous | Thread Next
Mark Overmeer
February 3, 2011 08:29
Re: setuid and serious trouble (Re: Time to update
Message ID:
* Leon Timmermans ( [110203 13:07]:
> On Thu, Feb 3, 2011 at 11:14 AM, Mark Overmeer <> wrote:
> >   sub setuid($) { $< = $_[0] }
> That is *not* what setuid(2) does. That would be violating people's
> expectations (and indirectly the standard). Worse yet, that would
> break people's code and open security holes. setuid is a mess, but
> let's not redefine what the function does.

$< uses setruid, setreuid (setting only uid), setresuid (setting only uid)
or setuid. (mg.c line 3310) In that order. The latter is PerlProc_setuid,
just as in POSIX.xs because both include XSUB.h which rewrites it via
a macro. Via iperlsys.h, however, it is translated back into the normal

It would be very unexpected to see  setreuid($uid, -1)  do something
different than  setuid($uid).  The former is to avoid race-conditions
when uid and euid both have to change.

Anyway, I do not have the POSIX standard on my shelf (yet). My HP-UX 6.5
reference (1988) does not differ from my Linux manual page about setuid()
(in logic to say, the text is completely different)

I do not see a functional difference between POSIX::setuid and $< But I
may have missed something. There may be differences between how various
operating systems interpret the call. We could document these differences
or at least warn for them. But the correct use of functions on a platform
is not the responsibility of Perl. Refering people who need a setuid()
functionality to the documentation of $< is an improvement.
PS: Leon, need a ride to FOSDEM this Sunday?


       Mark Overmeer MSc                                MARKOV Solutions                         

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About