Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Submission + - Disempowering the singular sysadmin 3

An anonymous reader writes: Practically every computer system appears to be at the mercy of at least one individual who holds root or whatever other superuser identity can destroy (or subvert, etc.) that system. Each application on a system has the same weakness. However, making a system require multiple individuals for any root operation (think of the classic two-keys to launch a nuke) has shortcomings: simple operations sometimes require root, and would be enormously cumbersome if they needed a consensus of administrators to execute. There is the idea of a Distributed Administration Network, which is like a cluster of independently-administered servers, but this is a limited case for deployment of certain applications... and anyway it is still presumably vaporware. Are there more sweeping yet practical solutions out there for avoiding the weakness of a singular empowered superuser?
This discussion was created for logged-in users only, but now has been archived. No new comments can be posted.

Disempowering the singular sysadmin

Comments Filter:
  • Best solution I've found is: multiple empowered superusers, heavily automated backups and the practice of hiring competent, trustworthy staff.

    • by ron_ivi ( 607351 )


      Plus good logging of anything done as a superuser.

      Best place I worked (from an IT point of view) had everyone with "sudo" capabilites, but everything done as sudo was logged and reviewed by the IT staff. Need to make a change as root - no problem - especially if you stuck to commands where they could pretty easily see what you did and why. And yes, you got yelled it very quickly if you 'sudo bash' and did a bunch of unnecessary stuff as root.

      It also had a live day-old-hot-backup (/yesterday) you coul

  • Organizations that would be impacted by a 'singular sysadmin' already take measures to counter that possibility.

    For instance, in an organization that I have worked with, the principle of assigning least privelege is adhered to strictly: users are given as little privelege as possible; helpdesk personnel only have enough privelege to modify computer settings (install printers and the like) and modify AD entries for the users in their section; progressively higher--more priveleged--levels require progressive

"If you lived today as if it were your last, you'd buy up a box of rockets and fire them all off, wouldn't you?" -- Garrison Keillor