[LINK] Dealing with modifications to the holy sudoers file

[Jon Seymour]

I recently spent some time writing a general purpose deployer script
for a multi-node install.

The script was designed to be run as a user, deployer, and it would
use limited privilege escalation via sudo to other accounts when it
needed more authority than it had.

So, for example, instead of putting a config file in a directory with
group-write permissions, the deployer would sudo to the required user
and pull the file into the correct place.
This meant that the directory only needed group read privileges but
the deployer could still update the file it needed to. Similarly, when
it needed to update an J2EE app server, it would
sudo su to that user and perform that task.

This was based on the idea of principle of least privilege - grant as
much authority as needed, but no more. The specification of the sudo
rules files was perhaps 2-3 screens
full and each of the 20-30 hosts could use the same rule set.

So far so good.

What I didn't count on was unix system administrators educated in the
stone age for whom sudo was and is 4-letter word in more ways than
one. Their definition of a good sudo file was a single file that could
be installed on my 20-30 hosts plus the other 970 hosts in their
organization. Any per application environment configuration is to be
treated with deep suspicion and hostility.  Better to grant group
write permission to the directory than let someone who knows what they
are doing do the right thing.

I clearly underestimated the sophistication of the support staff I
would have to deal with.

How do other people deal with such neanderthals?

jon.