If the process is running as the root user, it can change both it's real and effective uid. The catch is, you can only change these if your "effective" uid is 0 (root).

So, yes, you can change them midstream, but your effective uid had to be '0' when you started, and you'll have to reset it back to '0' before you change it to something else. Further complicating the matter, you can't set it to '0' unless your real uid is '0'. Whee.

This means the script has to be run as root, either directly, or via setuid flags on the script. This can be dangerous. Caveat Emptor.

Items to peruse:

• perldoc perlvar: see $>,$<,$(, and $)
• perldoc perlsec
• perldoc -f getpwnam,getpwuid,etc
• perldoc POSIX (getgroups specifically)

An example:

#!/usr/bin/perl -wT
#
# -T to set taint mode
use strict;
#
# setup ENV for taint mode
#
delete @ENV{qw(IFS CDPATH ENV BASH_ENV)};   
$ENV{PATH}="/bin:/usr/bin";
#
# die unless the process is running with
# an effective uid of 0 (root)
#
die "Must run as root" unless ($> == 0);
#
# explicitly set real uid to 0 (root),
# so that we can switch effective uid at will
#
$<=0;
if ($< != 0) {
    die "Couldn't set real uid to 0: $!\n";
}
if( my $id =getpwnam("http")) {
     # set the effective uid to http's uid     
     $>=$id;
     if ($> != $id) {die "seteuid failed: $!\n"}
     # run the id shell command that lists uid,euid,etc
     system("id");
}
if( my $otherid =getpwnam("nobody")) {
     # reset the effective uid to 0, or you won't be able to
     # set it to nobody's uid
     $>=0;
     $>=$otherid;
     if ($> != $otherid) {die "seteuid failed: $!\n"}
     system("id");
}
[download]

Update: I was addressing the question rather directly. (changing uid's midway through a script). It's probably a better idea to use two different scripts, and something like sudo or super that would allow one user to run a script as another user. Setuid scripts should be a last resort.

If you do not have access to root, I have used a script with a setuid permissions to do the trick. (man chmod will give you more information on that)

The idea is when you want stuff to be executed by a different account, you put those commands in a script file owned by the other account and then set the permissions using chmod so that when that script is executed it executes as the other account.

Now I should point out that this could be a security risk. But it really depends on what you are trying to do, what level of access the two accounts have, and what commands you need to run from the other account.

I described the way that I like to do this trick in Re: File Protections. As others have mentioned, you may need to worry about the security implications. In particular, your system administrator may take a dim view of suid programs. Check your local security policy to make sure that you don't get in trouble. You wouldn't want to get fired because you chose a computer language that was too powerful!

It should work perfectly the first time! - toma