Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
how about setuid/setgid flags? –  Sampo Sarrala Jun 8 '12 at 10:52
    
@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 Jun 8 '12 at 10:57
    
I republished this as serverfault.com/questions/397031/… –  Viktor Trón Jun 12 '12 at 19:12
add comment

2 Answers 2

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.

share|improve this answer
    
but as i said su called from script gives an error –  Viktor Trón Jun 8 '12 at 11:58
    
you should share how you're using it. I use su all the time in this context. –  mogga Jun 8 '12 at 12:41
    
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 Jun 8 '12 at 12:55
    
Your question has about 4 separate unrelated problems that need to be solved separately. The ssh error, group error have nothing to do with your question and you should read the man pages or post separate questions. –  mogga Jun 8 '12 at 14:07
1  
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 –  Viktor Trón Jun 12 '12 at 19:11
show 3 more comments

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
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.