On Tue, February 18, 2014 12:17, Alan McKinnon wrote: > On 18/02/2014 11:52, J. Roeleveld wrote: >> On Tue, February 18, 2014 10:47, Alan McKinnon wrote: >>> What I do run into is daemons that drop privs on start up, like >>> tac_plus. Unwary new sysadmins always try start/stop it as root, >>> causing >>> an unholy mess. Root the owns the log and pid files, when tac_plus >>> drops >>> privs it can't record it's state so continues to service requests but >>> fails to log any of them. For an auth daemon, that's a serious issue. >> >> Shouldn't sysadmins use the init-scripts for that? >> If done correctly, permissions should not be an issue. > > It's a little more complex than just that. It's an auth service and user > are frequently added, removed and modified. The daemon does syntax > checking on it's config file at startup or after being HUP'ed but that > only finds static errors. It catches things like adding people to a grop > instead of to a group, but misses dynamic mistakes like adding users to > groups that don't exist.
The auth-service gets the current state from a static file that is only read upon service-start? > It's exactly analogous to compile-time vs runtime errors, compilers > can't catch the latter. > > Despite this all being run out of cron with wrapper scripts to check > validity, automated additions and safety checks between all three > daemons, plus being fully documented on the internal wiki and in bold > blinking red caps in the login motd, people still find ways to do stuff > things in an attempt to fix it. (OT: Does the bold blinking red caps work on all terminals? :) ) > The daemon also tries to log these errors, by writing to a log file it > has no write permissions on. "setuid" on the group with group-write in the umask not an option? > There is nothing I can do about the quality of sysadmins, I have no > input into the HR process and damagement think cheaper is always better, > including skills. What I can do, is find ways to make the software more > resistant to errors than it already is. And only grant access permissions to these rookies once they have proven they understand rule #1: If In Doubt, Call Someone Who Knows! But yes, I fully understand the methods of HR and Damagement. It is a financial mistake and risk not to include technical expertise checks in the recruitement fase for technical positions. How much does it cost the company each time this goes wrong and someone like you has to come online to fix the issue? That is what Damagement needs to understand. -- Joost
