script calling script as other user

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:

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 training user to be set.

2. :

   su - training -c 'training_command' 
   

   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 Bash & 'su' script giving an error "standard in must be a tty" but i am reluctant and unsure of consequences.

3. :

   runuser - training -c 'training_command' 
   

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

4. :

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

I get 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.

Solution 1

Source the environment in your startup script if mugen kenichi's solution is not an option. I have some startup scripts that use mugen's approach and others that source the environment directly in the script. It's often simply a matter of preference. Sourcing the environment directly in the startup script is more transparent to other users who might edit the script (or you 6 months from now).

As my environment is made up of alot of conditionals it's easier to be implicit. Here's the first few lines from one of my startup scripts:

#!/bin/bash
. /my/tools/environment/apps/apps_rc
. /my/tools/environment/functions/common.bash 

Once this is done use su as normal to start the process as the user in question.

Here's a sample of how I start similar processes using su.

su -l $USER -c "nohup $APP_PATH" >> $LOG_FILE 2>&1 < /dev/null &

As an option you can also look at the daemonize package. I use it quite a bit as well.

Finally...

As from your question it appears as though you may want to run the script as a priveleged user you may actually need to set the setuid bit on the script to allow it to run as root by a normal use. This can have a security implication so know what you're doing when you do this.

Solution 2

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

Comments

[Sampo Sarrala - codidact.org]

how about setuid/setgid flags?

[Viktor Trón]

@Sampo would you mind elaborating? as I said setuidgid not enough cos I need env. or you mean that flag on runuser?

[Viktor Trón]

I republished this as serverfault.com/questions/397031/…

[Viktor Trón]

but as i said su called from script gives an error

[Z5678]

you should share how you're using it. I use su all the time in this context.

[Viktor Trón]

thanks for your attention. the script as in the OP is the /service/training/run executable, and i switch on the service with svc -u /service/training. supervise then launches the run script which fails since su needs tty stdin which is missing, so i get 'standard in must be tty' in my /var/log/training_service.log (and of course my training command is not run. hope this explains the context.

[Viktor Trón]

dear mogga, I got one problem that needs to be solved: run a script as another user (using that users environment, from a root script with no tty standard in). I just presented my 4 different attempts at solving it that all fail.

[Viktor Trón]

mogga, the ssh manual sheds no light on why host key verfication fails when supervise call my script, but runs perfectly when i call it from the terminal. thanks for your help

[Z5678]

there are many reasons why a key might fail... 1) it's not a matching key 2) the permissions on the key file are incorrect 3) the permissions on the .ssh directory are incorrect 4) your .ssh/config file is not correctly configured 5) the system sshd config ... these are just 5 possible places to look for problems

[Viktor Trón]

all of your 1-5 are ruled out by the fact that the command runs when the script called from a root terminal. but fails if called by daemontools without a tty. but thanks

[8bitjunkie]

This answer has been perpetuated all over questions like this but it is completely and utterly ineffective.