On the linux servers of our main customer our bash scripts were running under root for years. Now we want to change that for security reasons.

Some of our scripts were triggered by the "service" command, for example "service filescontrol start".

The main admin from our customer also wants these service triggered scripts to run under normal users.

But is the concept of the "service" command not bound to the root user?


service is a process like any other. Most of the time, it's /sbin/service. As we now have many "init" managers (RC-Scripts, upstart, systemd, svcadm...) each with their specialties, using service to manage startup scripts is a good point.

The modification you need to do it bound to the underlying system.

For example, on a init-rc system (the most usual) calling the script /etc/init.d/crond or calling service crond is the same :

$ service crond status
crond (pid  1837) is running...
$ /etc/init.d/crond status
crond (pid  1837) is running...

But with systemd, the issue is a lot more tricky as all is managed by the binary "systemd".

So, if you don't want to manage many systems and exceptions, you may consider using sudo. otherwise, you may start your scripts as user lambda, or use "set-uid" scripts.

  • Aren't there problems with SUIDing scripts? I seem to recall that's not allowed on some systems. Perhaps a selinux issue? – terdon Nov 12 '13 at 14:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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