Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I found an initscript that for some reason insists on starting the specified application as the root user. I can't wrap my head around why it is doing this, any hints? The script runs on Redhat Enterprise Linux 5.9.

# Start/Stop apfe.
# chkconfig: - 62 38
# description: apfe   
# Start script for an apfe process.
# Apfe does not normally run as root, so we change user
# and call the real script in $USERDIR.


share|improve this question

closed as off-topic by Iain, Dennis Williamson, MadHatter, Ward, Dave M Sep 30 '13 at 17:06

  • This question does not appear to be about server, networking, or related infrastructure administration within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

From what I can see it starts the apfe executable as apfe, not root – Mathias R. Jessen Sep 30 '13 at 7:43
Exactly, that's what I see too. But even so it starts and runs at root upon e.g a reboot of the system. – davidl Sep 30 '13 at 7:45
Are you sure there's nothing funky about the script $USERDIR/$PROGNAME? Try replacing the "$USERDIR/$ROGNAME $*" part with whoami >> /tmp/apfeuser.$$ (id -un >> /tmp/apfeuser.$$) to store the effective user ID the script runs as. If that's $STARTUSER, it's the called script itself that does something to alter the security context further. – Michael Kjörling Sep 30 '13 at 8:00
Sorry guys, it was I who was looking at the wrong process.. this script does indeed start the application as the user apfe. Sorry for wasting your time! – davidl Sep 30 '13 at 8:20
This question appears to be off-topic because PEBKAC ;) – Iain Sep 30 '13 at 8:33

Note that su - means command has to start in user login shell loading user environment too. In case that login shell is something like /bin/false for security reasons, there should be a problem.

Try to change su to sudo -u $STARTUSER ... and potentially do fine settings in /etc/sudoers for that command.

share|improve this answer
I still think it's much better to use -m switch then bringing sudo here. – kworr Sep 30 '13 at 8:43

I see a potential problem in that there's no full path to the su binary, and no guarantee you have a $PATH at all. My preferred solution would be to use runuser as opposed to su (see the postgresql startup file and man runuser for details) after sourcing the /etc/init.d/functions file, another solution would be to use the full path to the su binary. There may be other solutions available as well. Of course, this may not be the issue you're facing, but it answers your question of "What seems wrong". :)

share|improve this answer… – Iain Sep 30 '13 at 13:33

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