ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi, I'm planning to make a server/client program in Java, where the client connects to the server and the server edits files located on the server. What I want to know is, if the files are owned by root, what is the most secure way of editing the files? Should I just run the server as root, or is there a better way of doing it?
The most secure thing to do would be to change the ownership of those files such that your server can read and write to them. This would not only allow the server to run without root privileges, but would allow you to selectively choose which root-owned files can be edited and which cannot.
I wouldn't go as far as changing the ownership of the files unless your application is already rock solid security-wise. The safest way I see to do this is to copy-on-edit the files to a holding tank and require root to approve overwrites. You should use this method at least until your program is stable so that an error in the program doesn't do something catastrophic such as corrupt fstab or shadow or whichever critical file it might be editing.
To allow root to approve the changes, I would create an "approve" script which copies the files from the holding tank to their correct locations while backing up the old versions. This can be run by connecting via ssh remotely if necessary. You should, of course, access the files and check their validity before copying them into place.
ta0kira
PS In general, the only reason a server program should run as root is to start sub-processes under different user IDs. Normally the main process shouldn't access anything using the root user ID. Part of the security policy for the server I am writing specifically states that the server won't interact with the file system ever with a user ID of root.
I would say avoid being root where possible at all times.
perhaps you could change the file groups and make them writeable for
your servers group
or if not something like, say, a root server process reading a fifo or better a unix socket,
so your server gets a copy of the conf file, edits it, writes it's path to
the fifo and the root process does the rest?
or if not something like, say, a root server process reading a fifo or better a unix socket,
so your server gets a copy of the conf file, edits it, writes it's path to
the fifo and the root process does the rest?
That sounds like a good idea, but your server must then authenticate itself to the root process. That's not hard, but it is an extra step. I'd opt for using group privileges on the files if these things are to be written often. (Although if that were the case, the question "why aren't they owned by the user the server is running as" is begged.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.