This question doesn't really have anything to do with OpenBSD. Further questions about doing this stuff in perl are probably best taken to a perl mailing list or newsgroup. That's true of questions in the "why doesn't perl do <foo>" line: the people who make those decisions aren't normally found on this list.
On Sun, Aug 17, 2008 at 9:32 AM, Alexander Farber <[EMAIL PROTECTED]> wrote: > I hope I don't ask somtething too stupid, > but I'm trying to port a C-program to Perl > and for the drop privileges part of it I'd > need to call setresuid(). > > The following test at 4.3 returns a failure though: > > $ perl -M'POSIX qw(setresuid)' -e 1 > "setresuid" is not exported by the POSIX module > Can't continue after import errors at > /usr/libdata/perl5/i386-openbsd/5.8.8/POSIX.pm line 19 > BEGIN failed--compilation aborted. <sigh> To find out what the perl POSIX module exports, please run "perldoc POSIX" and read what it says. If you do so, you'll notice that it has no mention of that name. Indeed, that function *isn't part of POSIX*! > The perl config script does find > the setresuid during a "make build": ... > So why isn't it used by perl then? It is, to implement the magic of the $< and $> variables. Neither the perl core nor its 'standard' modules provide a complete interface to that function. > Is there a safe way to drop root > privileges in a Perl-script at OpenBSD? In accordance with the POSIX standard, POSIX::setuid() is sufficient for a process running as root, as that calls setuid() which changes all three uids (real, effective, and saved) to the specific value. > Several resources at the net tell > that $< and $> can't be used for the > purpose because they are cached "cached"? That seems either misleading or bogus. Perl does have magic to delay the effect of assignments to $<, $>, $(, etc until the end of the statement, but it only occurs in particular circumstances and it's neither indefinitely delayed nor 'cached'. (The delaying is only done so that compound assignments like this: ($<, $>) = ($>, $<); can achieve the goal of swapping real and effective uid.) As far as I can tell, the only real limitation on $< and $> is that perl does its best to never change the saved set-uid via those. Setting both $< and $> to some other uid will leave the saved set-uid as root. That process could restore its root privileges by setting $< and $> again. Philip Guenther
