程序可执行文件和日志文件的正确文件权限应该是什么？

Question

I have written a Linux system wide C++ program /usr/bin/PROG_X that uses a configuration file /etc/PROG_X.conf and log file /var/PROG_X.log .

Now I need to call this program, after strong authentication, from the web using apache web server and php. Calling the program may involve changing configuration files and will change, of course, log files.

I am interested in keeping SELinux enabled.

My Querstion is: What user/group and what file permissions should be set for the binary file, configuration files and log files for proper and secure operation?

Answer 1

For the most locked-down approach (assuming the log and config are sensitive):

Apache runs as user 'www', 'progx' user and group exists for the sole purpose of running /usr/bin/PROG_X.

/etc/PROG_X.conf is owned by root:progx, and has permissions 640
/var/PROG_X.log is owned by root:progx, and has permissions 660
/usr/bin/PROG_X is owned by progx:progx, and has permissions 500
/etc/sudoers allows www to run only /usr/bin/PROG_X as progx.

Thus, only root and progx can see the config or read/write the log file, and only root can modify the config. Only progx can run the program, but apache can specifically launch your program as progx via sudo.

[Edit: missed the part that said the program may need to change its config file... so the permissions would be 660 instead]

Answer 2

Well, I don't know about SELinux, but there several "traditional" solutions come to mind:

First, chown root /usr/bin/PROG_X and then set the setuid bit with chmod +s /usr/bin/PROG_X . The setuid bit causes the program to not run as the current user but as the owner of the file (in that case, root). This means you would need to really make sure your program is as secure as possible. So use with care.

An alternative to setuid might be to add an appropriate entry in /etc/sudoers for the program and call it via sudo . But it has the same security implications as the program will run as root, but at least you can be more fine-grained with the access (eg you could only allow the "www" user to run the program as root).

Another solution might be to chown root:wwwrun all_of_the_files_that_PROG_X_need_to_modify . But that would only work if you know exactly which files and also if that set of files doesn't change.