$< and setuid: quite different animals?

saintmike has asked for the wisdom of the Perl Monks concerning the following question:

Pop quiz: What's wrong with dropping privileges of a process, started as root, to "nobody", like this?

my $uid = getpwnam("nobody");
$< = $uid;
[download]

Answer: It's easy to regain root privileges afterwards by simply assigning 0 to $<.

Why is that? Turns out that assigning a uid to $< (or the effective uid $> for that matter) isn't using setuid(), at least not on Linux. Instead, it uses setreuid32() which allows the unprivileged user to switch back to the "saved set-user-ID". You can see what's going on in a perl script like

$< = $uid;
$> = $uid;

$> = 0;
$< = 0;
[download]

by looking at the strace output:

$ sudo strace ./switchback 2>&1 | grep '^set'
setreuid32(99, -1)                      = 0
setresuid32(-1, 99, -1)                 = 0
setresuid32(-1, 0, -1)                  = 0
setreuid32(0, -1)                       = 0
[download]

The last two calls successfully restore root privileges (uid and euid) while running as an unprivileged user.

Question: What's the best way to drop privileges, then? POSIX:setuid( $uid ) seems to work, is that the best practice?

Comment on $< and setuid: quite different animals? Select or Download Code

Replies are listed 'Best First'.

Re: $< and setuid: quite different animals?
by almut (Canon) on Apr 10, 2010 at 06:52 UTC

Try it the other way round (first effective, then real):

$> = $uid;
$< = $uid;
...
[download]

$ sudo strace ./switchback.pl 2>&1 | grep '^setr'
setresuid(-1, 65534, -1)                = 0
setreuid(65534, 4294967295)             = 0
setresuid(-1, 0, -1)                    = -1 EPERM (Operation not perm
+itted)
setreuid(0, 4294967295)                 = -1 EPERM (Operation not perm
+itted)
[download]

[reply]
[d/l]
[select]


go ahead... be a heretic
	PerlMonks