Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an application which runs as a daemon and is controlled by a script in /etc/init.d
Sometimes we need to change some parameters of startup/control of these scripts and then restart the daemon. These scripts only have write permission for the root user, so when editing these scripts I need root privileges.

What I was thinking is that should I make a non-root user the owner of those scripts. This way only root and a special user can edit these scripts.

Is it acceptable to keep some non-root owned files under /etc/init.d directories?
Or it is absurd, disturbing the natural order of the system?

share|improve this question

migrated from stackoverflow.com Jan 30 at 10:18

This question came from our site for professional and enthusiast programmers.

bad idea, don't. –  ChuckCottrill Jan 30 at 19:52

2 Answers 2

up vote 16 down vote accepted

What immediately comes to mind is an underprivileged user being able to run things on boot as root, which is desirable to crackers that:

  • Want to escalate privileges of other accounts
  • Want to use your server to host a rogue service
  • Want to start IRC/Spam bots if the server reboots
  • Want to ping a mother ship to say "I'm up again" and perhaps download a new payload
  • Want to clean up their tracks
  • ... other badness.

This is possible if your underprivileged user is somehow compromised, perhaps through another service (http/etc). Most attackers will quickly run an ls or find on/of everything in /etc just to see if such possibilities exist, there's shells written in various languages they use that makes this simple.

If you manage the server remotely, mostly via SSH, there's a very good chance that you won't even see this unless you inspect the init script, because you won't see the output at boot (though, you should be using something that checks hashes of those scripts against known hashes to see if something changed, or version control software, etc)

You definitely don't want that to happen, root really needs to own that init script. You could add the development user to the list of sudoers so that it's convenient enough to update the script, but I'd advise not allowing underprivileged write access to anything in init.d

share|improve this answer
tl;dr: If you do this, the non-root user is as good as root on the next boot. You're begging to be pwned. –  Warren Young Jan 30 at 10:38

In addition to the very good points made by Tim Post, I'd add that for a setup where multiple people need to be able to push changes onto a server, you should consider using some kind of configuration management system.

If you e.g. use puppet, or chef, or cfengine, you can have the relevant users edit the files locally and then push the changes out with the config management. Exactly how to set this up will of course vary depending on which system you're using, but properly set-up it will include versioning software making it easy to revert to an earlier version of a config file when (note: when, not if!) someone's made a mistake. It will also make it easier for you to copy configuration to a separate test system etc.

share|improve this answer
Keeping both your scripts and even your configuration data files versioned in a configuration/version management system is an excellent idea, even without considering whether a system could be compromised. –  ChuckCottrill Jan 30 at 19:51
Indeed - I've used it for fixing mistakes about a couple of magnitudes more often that I've used it for fixing a compromised system. –  Jenny D Jan 31 at 6:56
Thank you very much . Because here mostly a dedicated user uses this application so sudo is quitely working and this what I was doing from long time. BUT I am REALLY very much interested version management system for the configs . Dear Jenny can you provide me any refrence for doing so OR ANY EXAMPLE!! :). –  Akaks Jan 31 at 7:10
If you don't want to go with the full puppet/chef/cfengine etc route, I would personally use www.perforce.com. We used that for ~100 servers in the time before puppet existed and their eval license is enough for one server. The main advantage is that you can checkout VC'd files to any place in the file system instead of being limited to one subpath. Other options are joeyh.name/code/etckeeper , or using any VC combined with scripts to move files to the proper directory. –  Jenny D Feb 1 at 9:11

Your Answer


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.