sudo is a pretty cool command because it lets you control, in a granular way, who can execute what commands as who.

Well, while this method is all well and great, it doesn't subscribe to central authentication. So in the event that an account gets compromised, and that account is used on multiple machines, you have to go to all the machines and remove the user from the sudoers file.

In the Kerberos world, there is a nifty feature called the .k5users file which provides a means of doing sudo-like things.

Joe first clued me in on this feature but it didn't click until recently. With nagios, we have some checks that can be fixed programatically. The problem is that nagios doesn't have any privileges on the box and it will need root privileges to accomplish its task.

First I thought to use sudo. It logs usage of sudo, but it doesn't subscribe to our central auth policy. Next I remembered about k5users. It just so happens that you can do the same sort of thing.

First, make a file called .k5users inside the home directory of the user who you want to be able to run commands as.

Next, add lines to that file. The format is

  • principal@fully.qualified.domain@DOMAIN.FOO    /path/to/command</li>
    After that, you can use the ksu command to run that command as that user, like so.
    • ksu user -n principal@fully.qualified.domain@DOMAIN.FOO -e /path/to/command</li>
      And just like that, it will work if you have a valid kerberos ticket. The trick to making stuff like this word from cron and automated things is to store your principal in a keytab and refresh your ticket cache every now and then (like every night at midnight) using the keytab. This isn't hard either though, and only requires a simple crontab entry for the user who will own the credential cache. Something like this
      • kinit -kt /path/to/keytab principal@fully.qualified.domain@DOMAIN.FOO</li>
        Best of all, you get the benefits of kerberos and sudo with this example
        • limit elevated access to a single command</li>
        • ksu logs usage</li>
        • kinit logs refreshing of creds</li>
        • central killswitch at the KDC to disable this princ if it gets compromised</li>