Re^3: Automating sudo actions

[GrandFather]

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.

[rastoboy]

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.

[tilly]

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";

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.)

[JavaFan]

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

[cjb]

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

[MidLifeXis]

I hope that you meant, at most, the perl script. Be aware, however, that even this is not the first (or often the best) hammer in your toolbox. If you actually meant the perl executable itself.....

... ick ick ick. If I then have access to your perl suid executable, I now have root on the box. If I am using your suid perl executable for anything else, that anything else is now running as root on the box.

The concept of least privileges would use that tool (suid) for a very limited application, with a very tight environment - never for something as powerful as the perl interpreter itself.

Now, will it even allow itself to run suid root? I don't know if perl will allow you to shoot yourself in the foot hand a loaded gun, pointed at your foot, with a hair trigger, around a room of drunks, telling them that it is unloaded, while applying electric shocks to the person holding the gun just to see them twitch or not.