[unisog] root level access policies?
feenberg at nber.org
Mon May 9 15:29:54 GMT 2005
On Mon, 9 May 2005, John Meyers wrote:
> I was just curious what other schools have implemented in terms of
> policies related to root level access on production servers? For
> example, do you provide your dba's or other IS staff who are primarily
> working with applications root level access?
No matter how hard you try to keep root access from IS staff, the OS is
never as cooperative as you will want it to be. Our Linux boxes will
sometimes ask for the root password at reboot (for fsck after an unclean
shutdown). If the db server is down, should the dba be able to reboot it?
You will encounter similar issues freqently.
(I know some will answer that the mere fact of a required fsck is a sign
of moral failing which should not be comensated for by the further sin of
giving the dba root passwords. However, system administration isn't my
Also, it will depend a lot on how your systems are organized. If you have
a dedicated db server, it makes sense to give root permissions to the dba,
whereas if the db ran on a shared server, it might not. Note that this is
both because root means more on the shared server, and because the dba
admin may be able to count on a shared server being serviced by systems
staff, while he may expect a single purpose server to be neglected.
It also depends on the confidence you have in your staff, and other local
issues. It is easy for someone to write a guideline says "best practice is
no one has root", but they don't live in your world. Lastly, remember that
anyone with physical access to the computer has effective root. The
password is there only to keep honest people honest.
We use sudo for all root access, but wish we could keep a log of commands
issued when the user runs:
and then works in the new shell as root. sudo only logs the "csh" command,
not the commands to the shell itself.
More information about the unisog