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 sftp-user.
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?