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

$<, $>, $( and $) cannot always be believed.

Paul Fenwick
May 26, 2004 01:28
$<, $>, $( and $) cannot always be believed.
Message ID:
G'day everyone,

	Firstly, a little background.  I'm currently working upon a module, 
tentatively named Proc::UID, to allow manipulation of Unix UIDs in a 
consistent fashion.  The module is designed to include support for UIDs 
other than just the real and effective UIDs ($< and $>), including the 
commonly seen saved-UID, and the more exotic filesystem-UID.

	One of the goals of Proc::UID is to provide a consistent interface to 
UID operations which are commonly required, but the implementation of 
which is different depending upon platform.  One example is being able 
to permanently drop privileges, something which '$< = $> = $UID' does 
not always achieve.  Further information behind the motivation of 
Proc::UID can be found at the module registration (previously called 
Secure::UID), here:

	A good discussion on the UID differences between operating systems can 
be found here:

	The module is currently in a fledgling stage, and I'm concentrating 
most of my efforts on a good regression testing suite, to ensure that 
the code actually does what it claims to do.  One of the discoveries I 
found is that $<, $>, $( and $) cannot always be believed.  A set*id 
call in XS can update the privileges of the currently running process, 
but $<, $>, $( and $) do not reflect this.

	This problem was discovered in RT #24641: Failing  POSIX::getuid/getgid 
and related ops ( 
In this ticket it was found that calls to the POSIX::setuid and 
POSIX::setgid did could change the UID of the process, but Perl's 
special variables did not reflect that.

	The solution in RT #24641 was to set PL_uid and PL_euid (and their gid 
siblings) directly in XS.  While this solves this particular problem, 
and also works for Proc::UID, it does not solve the problem that Perl's 
special UID variables can end up in a situation where they hold 
different values to the actual privileges of the process.  This is a Bad 
Thing -- if a program is testing $< or $>, it's almost certainly wants 
that result to be reliable, and may do something foolish thinking it has 
more or less privileges than it really has.

	Well-designed XS code should ensure that Perl's UID variables are kept 
up-to-date, but this still allows bugs to hide in poorly designed code, 
or well-designed code that's not sufficiently tested.  It would be nice 
if $<, $>, $( and $) actually resulted in calls to the underlying get*id 
system calls, rather than displaying what PL_*id was last set to.

	My purpose for posting today is to determine if anyone is already 
working upon this issue (or if it's already been fixed in 5.9.x).  If 
this is not yet an issue that is being addressed, are there any 
architectural barriers to doing so?

	Many thanks,


Paul Fenwick <> |
Director of Training                   | Ph:  +61 3 9354 6001
Perl Training Australia                | Fax: +61 3 9354 2681 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About