How is that different than using sudo from the command line? In my (limited) experience with *nix sudo is required to prefix each command that requires privilege. You can of course capture the output from the commands you run should you need to further process or log the results. That in addition to setting up passwordless sudo permissions ought allow you to do all you've described so far.

Okok my bad, sorry. I had a feeling I wasn't asking my question right, but I couldn't put my finger on it--but you've shown me the problem. What I'd like to do is 'sudo su' or 'sudo bash' and execute system calls within that environment.

It's not quite as asinine as it sounds--it's just the limitations I find myself working under, and it's simply not possible for me to change the environment. Actually I suppose it is a bit asinine, but I'm still intensely curious if it's possible without Expect.

It's come up in other situations as well, such as automating tasks via Net::OpenSSH needing privilege escalation--or sudo with a password over the connection, where I need to issue a series of commands where the output of one command will determine some of the syntax of the next one. So I can't very easily just chain them up with &&'s.

There is always a possible hack. For instance you can:

open(my $shell, "|-", "sudo perl") or die "Can't pipe to bash: $!";
print $shell "$password\n";
sleep(1); # Make sure that Perl has started.  This is likely unneeded.
print $shell $some_perl_script;
close($shell) or die $! ? "Error closing pipe: $!"
                        : "Exit status $? from perl child";
[download]

And now you can execute an arbitrary Perl script, as root, without installing anything. (Assuming that you have the password.) You can do the same thing over ssh.

Of course this is very much the wrong way to do it. Your root password is now available to anyone who can read the script. A much, much better approach is to find standard, more secure, ways to get a passwordless escalation. For instance locally use setuid. Remotely you can follow the advice at http://www.debian-administration.org/articles/152 and set up secure passwordless logins that use secure public keys. (If you're doing this from a shared box, you may want to set those up from some privileged account, and then have setuid scripts that can run as that account.)

Shells are for interactive business. That is, *non* automated. If you're automating stuff, you do not want an interactive shell.

Is there any reason you don't just run the perl setuid root? (with -T perhaps?)