Linux – Redhat init script best practice

init.dlinuxlsbredhatrhel5

I want to write an init service script which runs the program as a particular user (and not root). I will then chkconfig this script and install into my production run level.

I could just put a su command in the script but I was wondering if there is a best practise of doing this.

Thanks,
Garry

Best Answer

You can just su. You won't need the password because the script will initally be running as root.

There's also the runuser command.

If you use /etc/init.d/functions you can use the daemon function which has an option for specifying the user to run as.

I'd personally sway towards the latter all other things being equal.

Related Solutions

Linux – Best practice for multi Admin root access

We use sudo configured to allow commands from the group. To prevent the sudo -i or sudo bash, I have setup an alias including all known shells which I disallow using ! in the definition of what the group can do. That way, all commands run with sudo are logged to syslog. The only shell I have installed and allowed is rootsh, which logs everything done from it.

Cmnd_Alias SHELLS= /bin/sh, /bin/ksh, /bin/bash, /bin/zsh, /bin/csh, /bin/tcsh, /bin/login, /bin/su
%admin ALL = (ALL) ALL, !SHELLS

Obviously, nothing can stop an admin to

cp /bin/bash /tmp/shell
sudo /tmp/shell

in order to bypass this security, but still you give them root rights, you have to trust them anyway...

Linux – Why does redirecting ‘script’ to /dev/null/ allow ‘screen’ to work while su’ed as another user

Well, technically you're not redirecting anything here.

Calling script /dev/null just makes script save the whole typescript into /dev/null which in practice means discarding the contents.

See man script for detailed info and util-linux-ng package for implementation (misc-utils/script.c).

This has nothing to do with screen actually. Why this works is invoking script has a side effect of creating a pseudo-terminal for you at /dev/pts/X. This way you don't have to do it yourself, and screen won't have permission issues - if you su from user A to user B, by directly invoking screen you try to grab possession of user A's pseudo-terminal. This won't succeed unless you're root. That's why you see the error message.

Best Answer

Related Solutions

Linux – Best practice for multi Admin root access

Linux – Why does redirecting ‘script’ to /dev/null/ allow ‘screen’ to work while su’ed as another user

Related Topic