[nSLUG] Dealing with a superior who believes they need root
ssmith at cs.dal.ca
Fri Nov 3 16:25:25 AST 2006
Don't bring it up from a strictly IT perspective. If any of this
potentially interferes with what the customer does (say a customer
accesses some data from your servers or something), point out that
your boss is actually costing the company more money by having root
access. Not only does the company lose value to the customer when said
individuals screws things up, but IT also has to spend time fixing
things, which is time and money that could be better spent elsewhere.
Adapt as needed for your own situation.
On 11/1/06, D G Teed <donald.teed at gmail.com> wrote:
> This is not specific to Linux, but as it touches on best practise for
> *nix, I thought it might be an interesting discussion for the group.
> This happened to a friend of mine...
> Suppose your *nix savvy boss is laid off, a junior manager is
> made into your new boss, and they know Windows and
> networking and just enough Perl to be dangerous.
> The new boss has root access to the DHCP/DNS server
> through legacy arrangement, and uses it to update
> host management shell and Perl scripts. In the course
> of doing that, (a) a cron script is left in an edited and untested state,
> breaking DHCP, (b) /etc/init.d/dhcpd is edited for the sake of
> the cron (rather than making PATH set in a wrapper script),
> and (c) a dhcpd.log archive is accidentally deleted.
> After the third problem, the sys admin asks the boss's boss
> if they can remove the boss with root from that level of
> access and use groups for read only access that the
> network staff need to use. However the boss's boss
> knows little about IT - is a financial manager actually.
> The challenge is: how to demonstrate to the boss's boss
> that the boss is breaking good *nix sysadmin practises
> and should leave the sysadmin tasks to those with
> experience and knowledge of good practise.
> To put it another way: where can one find an authority source
> a non-IT person can understand, which discusses best practices
> for *nix sysadmin and security - possibly in condensed reading
> format rather than full book.
> nSLUG mailing list
> nSLUG at nslug.ns.ca
More information about the nSLUG