how to specify password for sudo command when running bg process?
 

I'd like to start a background job using the sudo command and route its output to a file.

This presents a problem because the prompt for the password doesn't work properly.

It looks something like this when I try it:
Basically I'm not properly prompted for the password and as soon as I type anything in my background job fails because it didn't receive the password.

Is there any way to execute a sudo command by supplying the password on the same line as the command?

Why not use screen instead of backgrounding the process? Or alternately specify you can run that command without a password via the sudoers file.

Thanks for your response!

I'm not exactly linux master myself, so I'm not familiar with the screen command. I'll be reading the man pages here shortly. One thing to note is that I'm using this command to start a server daemon so the process must continue running when the terminal window closes.

A major issue is that I'm trying to write some very simple instructions for people who might not be linux masters and I don't expect they'll know how to go and alter the sudoers configuration. I'm still trying to figure that out myself.

I think what I'd really like to do is create a shell script which will prompt the user for the password and then run the appropriate command, backgrounding the process and storing its process id in a file for possible termination later.

What I'd REALLY like to do is set this up like a service that would start up when the server reboots like httpd or mysqld with commands like
FYI, this is what I'm working on.

The solution for the problem in the opening post is given in the page that you refered to (and yes, it's a workaround). Run sudo ls -l and enter your password; next run sudo php crossdomain_server.php > data/crosscomain_output.txt &; this works because the sudo password is remembered for a short while (usually 5 minutes); read the sudoers manpage

You can also exclude certain commands from requiring a password (again, see the sudoers manpage).

That other link I provided is something I wrote myself. I need something better because I would like to provider either a single shell script (e.g., "start.sh") or set up this system so that the daemon can be launched via a browser without the password ending up in a shell history somewhere.

I've read the sudoers man page and I want to spare users of my software the chore of editing all the sudoers-related files.

I'll break this down into several options of what I'd find satisfactory and just pray that people have feedback.

Acceptable solution #1 - shell script that prompts for password
As I mentioned in the original post, when I login via SSH and attempt to start a daemon process using sudo while a) backgrounding it and b) writing the output to a file then it doesn't work -- the password prompting somehow fails and when I try to type my password in, it appears as plain text which is not cool and the password is not routed to the prompt but rather interpreted as a command. FAIL.
e.g.:
An acceptable solution here would be the creation of a script that would either prompt me for a password and then call the sudo command for me OR write a script that I can just call using sudo so I am prompted for the password immediately and the contents of the shell script take care of backgrounding and routing output.

DOWNSIDES: Have to login via SSH to start my daemon process. Really worried about root passwd ending up in a bash history file, possibly readable by other users on shared hosting environment. General security worries.

Acceptable solution #2 - securely hosted web page that prompts for password
I've seen things like cPanel and Webhost Manager that let you do things like restart mysql or restart apache or even reboot the server. I would love a situation where the webpage (HTTPS hosted of course) prompts the user for a passwd and then supplies it to an [man]exec[/man] command. The problem is that sudo lets you specify the command but then prompts you for a password. As far as I know, exec and sudo don't really play nice together. This is the optimum solution because the PHP web form can only call sudo if the user supplies the write password. Unfortunately, I don't see how to get it to work.

DOWNSIDES: Does using "echo PASSWORD | sudo -S command" result in my root password ending up in a bash history file? This sounds insecure. How much of a security risk is it to temporarily write the root password to a file and use sudo -S to read password from the file?


Acceptable solution #3 - securely hosted web page with sudoer apache
I know you can add apache as a sudoer, but I'm really really concerned about giving apache any kind of sudo capability lest it be abused--especially if the acccess is NOPASSWD. I'm looking into how I can use the sudoers file, but would much prefer if the user must enter some kind of password AND if the the sudoer privileges apply ONLY to one or two scripts.

DOWNSIDES: Security risk in giving sudoer privs to apache. Setting up this kind of privilege involves edits to the sudoers file and possibly other permissions changes I don't yet fully understand which will likely be very confusing to people trying to run my software.



Any feedback or suggestions are welcome.

The users of your script should not edit the sudoers file; that is the task of the 'root' user.

I don't have (much) experience with sudo, but as far as I know you can use system groups in the sudoers file as well. So make users a member of a group myspecialgroup

From the examples in man sudoers, my first attempt would be a line like below in the sudoers file
This will allow users in the myspecialgroup group to run only myprogram without a password and will not affect any other command.

#4 Good & clean solution:
Write a shell script that uses full paths and starts
the server. Put that into /etc/init.d ... symlink it
to rc3.d with a numeric ID that's higher than apaches.



Cheers,
Tink

I love your suggestion, Tink. Is that specific to any particular flavor of linux? I've seen plenty of /etc/init.d commands on debian but on the CentOS boxes I deal with, it's /sbin/service.

I'm working on this particular issue in order to get a more convenient way of launching a couple of socket server daemons for Flashmog (see my signature) so the idea is to create a system that can easily be downloaded and installed by developers when they want to use FlashMOG. FlashMOG is not so much an application as a code library. It's a code skeleton that's meant to be modified rather than a fully functioning server.

Complicating matters is the problem that a Flash crossdomain server (one of the two daemons I'm launching) must bind to port 843 so you can only have one instance of the crossdomain server running on a machine at a given time. I was thinking it might be nice to create an RPM or package for the crossdomain server so you can just apt-get install flashmog-crossdomain-server or whatever. But I'm still confused about how to make FlashMOG server (the code to be modified) more convenient.

I've managed to get a version of acceptable solution #1 in place. I have a shell script:
I can launch it with sudo thusly:
I get the password prompt and it runs in the background, routing script output to one file and writing the PID to another file.

Then I can terminate the process with this script
sudo required for that one too:
I'd really like to do something like you have suggested, but I'm still wondering two things:
1) how to generalize this to work on all flavors of linux
2) how to get absolute paths? Keep in mind that one might want several different FlashMOG server projects on a given machine, but there can be only one crossdomain server.

'service' as far as I'm concerned, is just a front-end to
scripts in /etc/init.d ... so creating the script (ideally
with the required chkconfig lines at the top) once should
work on debian & RHEL (and their respective derivatives).



Cheers,
Tink