run script as another user from a root script with no tty stdin

Question

Using CentOs, I want to run a script as user 'training' as a system service. I use daemontools to monitor the process, which needs a launcher script that is run as root and has no tty standard in.

Below I give my five different attempts which all fail.

1. :

   #!/bin/bash
   exec >> /var/log/training_service.log 2>&1
   setuidgid training training_command
   

   This last line is not good enough since for training_command, we need environment for trqaining user to be set.

2. :

   su - training -c 'training_command' 
   

   This looks like it (Run a shell script as a different user) but gives 'standard in must be tty' as su making sure tty is present to potentially accept password. I know I could make this disappear by modifying /etc/sudoers (a la https://superuser.com/questions/119376/bash-su-script-giving-an-error-standard-in-must-be-a-tty) but i am reluctant and unsure of consequences.

3. :

   sudo -u training -i bash -c 'source $HOME/.bashrc; training_command'
   

   A variation on the same theme: 'sudo: sorry, you must have a tty to run sudo'

4. :

   runuser - training -c 'training_command'  
   

   This one gives runuser: cannot set groups: Connection refused. I found no sense or resolution to this error.

5. :

   ssh -p100 training@localhost 'source $HOME/.bashrc; training_command'
   

   This one is more of a joke to show desparation. Even this one fails with Host key verification failed. (the host key IS in known_hosts, etc).

Note: all of 2,3,4 work as they should if I run the wrapper script from a root shell. problems only occur if the system service monitor (daemontools) launches it (no tty terminal I guess).

I am stuck. Is this something so hard to achieve?

I appreciate all insight and guidance to best practice.

(this has also been posted on superuser: https://superuser.com/questions/434235/script-calling-script-as-other-user)

Solution 1

You will need to disable the requiretty setting in /etc/sudoers for root. Add the following line via visudo:

Defaults:root !requiretty

You will also need the following line in /etc/sudoers so root can do everything (this should be enabled by default, but check to be sure):

root ALL=(ALL) ALL

Then you can do the following:

sudo -u training /path/to/training_command

Solution 2

This seems to be essentially a special case of this question; we can use script -c to fake a tty. The only problem is that I can't get that trick to work directly with su for some reason, and sudo is a bit ugly if you really have to source ~/.bashrc before training_command. Try:

echo password | script -c "sudo su - training -c training_command" 

Comments

[Viktor Trón]

thanks Alex. Alas, sudo does not set the environment only if used with -i option. plus it still complains about missing tty if invoked by supervise. see my edited question including a variant of this.

[AlexT]

You are right. Then su - training --session-command=training_command >> /var/log/training_service.log 2>&1 should do it.

[Viktor Trón]

Thanks Alex but as said su gives 'standard in must be a tty' if called from script.

[Viktor Trón]

Thanks Tamas. But. Setuidgid only sets the owner of the process not the environment. I really do need to be training user with its environment to run the command. your solution of putting 'YOURVARIABLE=yourvalue' does not do justice to this. I need to replicate exactly what a login shell sets and do not want to rely on knowing anything about the command beyond that. I can't believe there is no solution to this simple problem and how come noone ever ran into it. I think I am missing something...

[Monty Harder]

@ViktorTrón: Log in as training. Execute the command set >training.set Log out. edit cstamas' script above to insert the line . /home/training/training.set right before the last line. It should set every environment variable that was set by the login process to the same value it had when you logged in manually. You may need to edit that file and remove one or two variables that might mislead your program, but you probably don't even need to do that.

[mpez0]

You want to also unset variables that are not part of the training environment. I'd use "su training /bin/sh -c ". <set up environment>; runcommand". That works for me for setting up system services.