develooper Front page | perl.perl5.porters | Postings from May 2004

Re: Does Perl need a special variable for saved-UID/GID?

Thread Previous | Thread Next
From:
Paul Fenwick
Date:
May 31, 2004 09:21
Subject:
Re: Does Perl need a special variable for saved-UID/GID?
Message ID:
40BB5383.9070103@perltraining.com.au
G'day Rafael / p5p,

Rafael Garcia-Suarez wrote:

>>	* Does Perl need two more special variables (one for saved UID,
>>	  and a second for saved GID)? Would it be better to include a
>>	  module in the standard distribution which could provide
>>	  functions/tied variables for people who need to manipulate
>>	  saved UIDs?
> 
> If the corresponding syscalls are part of POSIX, the natural place is to
> add them in POSIX.pm, which already provides setuid() et alii.

The POSIX specification does define saved UIDs, but defines only very 
round-about ways to manipulate them.  It does not define the 
setresuid()/getresuid() calls, which are most useful for this purpose. 
One of the problems with POSIX is the calls that *are* part of the 
standard, particularly setuid(), can be frightfully confusing.

As an example, setuid($newval) sets all the uids to $newval when 
executed with effective root privileges.  When not running with 
effective root privileges, it sets only the effective UID.  The 
exceptions to this are under FreeBSD, where it sets them all, or Linux 
which sets them all if the 'setuid capability' is active.  The setuid 
capability can depend upon the effective UID, but can also be set 
independent of it, and is not based upon a POSIX standard.

The more consistent and well behaved calls, particularly setresuid(), 
are not POSIX standards.  Where they do exist, they are a joy to behold, 
but some systems (eg, Solaris) that have saved UIDs do not provide the 
calls to easily manipulate them.

Linux adds filesystem UIDs and GIDs (fsuid/fsgid) to the mix, but only 
provides calls to set these values, not to read them.

Ton Hospel directed me to 
http://www.cs.berkeley.edu/~hchen/paper/usenix02.html (Setuid 
Demystified -- Hao Chen, David Wagner and Drew Dean).  The paper is very 
detailed and well thought-out, and suggests an API to allow navigation 
of the set*id calls in a cross-platform fashion.  In particular, it 
suggests the implementation of:

	drop_priv_temp($uid)
	drop_priv_perm($uid)
	restore_priv()

which have much simpler to understand semantics than the traditional 
POSIX calls.  These cover the most commonly required privilege 
manipulations, and it *should* be possible to define these on all 
systems that have the three concepts of real/effective/saved UIDs.

My inclination would be to provide these functions as a consistent 
interface to UID manipulation.  This may be in addition to the regular 
get*id and set*id calls where available.

> I'm not against adding a lightweight Proc::UID in the core; given that
> the documentation about UIDs in various parts of the man pages could be
> updated to point at this module, explaining in further details the
> concerns about not using the saved UID.

Why, it so happens that I have a fledgling Proc::UID module here.  It 
still needs a lot of work, as it's only recently hatched, but I'm happy 
to put it up for consideration once it's matured somewhat.

One of the challenges in writing any module or code to manipulate Unix 
UIDs is that testing requires processes to run with special privileges 
(either root or setuid).   I imagine that most people running automated 
tests are not running them as root.  I suspect I'll be doing a bit of 
begging/borrowing to ensure that Proc::UID is well-tested across many 
platforms.

> (And, a probe should be added to Configure for the availability of saved
> UIDs.)

Some of these may be difficult to detect.  I believe that Solaris 
requires mucking with /proc to read the saved-uid of a process.  However 
it kindly defines _POSIX_SAVED_IDS to let you know it's there.

> I don't think perl needs two more special variables; we're running out
> of ASCII. (No support for Unicode special variables yet :)

Good.  I think that's for the best.  I didn't want a $} or $>) anyway.  ;)

Cheers,

	Paul

-- 
Paul Fenwick <pjf@perltraining.com.au> | http://perltraining.com.au/
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About