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?
Best Answer
What immediately comes to mind is an underprivileged user being able to run things on boot as root, which is desirable to crackers that:
This is possible if your underprivileged user is somehow compromised, perhaps through another service (http/etc). Most attackers will quickly run an
lsorfindon/of everything in/etcjust 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