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