Nicolas Williams wrote:
> On Thu, May 15, 2008 at 10:07:51AM -0400, Bill Sommerfeld wrote:
>> folks interested in solving this may want to look more closely at the
>> Kerberos "ksu" scheme invented at Project Athena; rather than having a
>> shared password, people who have administrative roles are issued one or
>> more secondary principals, each with independent passwords (via the
>> kerberos "instance" naming convention). Rather than one shared password
>> on the role account, each user gets their own "root instance" password.
>> Actions taken as a "root instance" are attributable to an individual
>> person, while the regular user account and password are only as powerful
>> (and thus only as sensitive) than an account without special powers.
>
> But note that there's no need for us to use ksu to get the same result.
>
> We've previously discussed, more than once too, a user_attr for roles
> that says that users assuming the role use not the role's shared
> password but their own (or an alternate per-user password). There's no
> reason we shouldn't do that.
Having users assume a role using their own login password is ideal since
there are no additional passwords to remember. We didn't do it that way
10 years ago because we needed to generate the role's NIS+ credential
using a different password (but the same one for anyone who assumes the
role).
I'm thinking that one of the following is probably true now:
1. We no longer care about roles acting as NIS+ principals [NIS+? What's
that?] and we have no other situation where a credential is generated
from the login password.
2. If #1 is not true, we can store the role's credential (in the role's
home directory, for example) so that it can be accessed only by the role
account. In general, this solution doesn't work for NIS+ credentials
because superuser access on a client machine would override file
permissions. Of course, one could administratively arrange for the file
containing the credential to be NFS-mounted from a server that does not
grant superuser access to remote clients.
Scott
