A shell script (
myscript) will be run as root, by
cron. It reads IP addresses from a configuration file, and updates
iptables to whitelist those IPs for inbound connections.
myscript uses a regexp (regular expression) to parse the configuration file for IP addresses at the beginning of lines. There is no obvious risk of a buffer overflow or a privilege escalation, because anything that doesn't match the structure and length of an IP address is ignored.
For operational reasons, this configuration file must be updatable by a specific, trusted person whose only access is via SFTP from an old-fashioned GUI SFTP program that is incapable of authenticating to
sudo. (Think CyberDuck, FileZilla, WinSCP.) This person should not do anything else on the machine. Clearly, they should log in via a non-root account. Let's call their account
If the configuration file had
root:root as owner and group, as most GNU/Linux configuration files do, then AFAIK the only way for
sftp-user to edit them would be if the
sftp-user account had passwordless
sudo privileges. This would be dangerous: it would give the account much more power than necessary. So, a less risky alternative is needed.
My question is: of the following, which is the least risky set of permissions for that configuration file to have, and why?
permissions owner group ----rw---- root sftp-user -rw------- sftp-user root -rw------- sftp-user sftp-user
Edit in response to David's helpful answer: Yes, in normal circumstances, the permissions above are equivalent. Assuming the only member of the
sftp-user group is
sftp-user, then each of them allows read-write access only to
sftp-user and to
root. But what about extraordinary circumstances: does one of the configurations then pose less risk than the others? E.g. have there been cases of privilege escalation via file ownership alone, such that mixing a root owner and non-root group (or vice versa) is a bad idea?