Processing .k5login (another patch)

[Russ Allbery]

"Roland C. Dowdeswell" <elric at imrryr.org> writes:
> On Wed, Sep 01, 2010 at 03:49:57PM -0700, Russ Allbery wrote:

>> The common scenario here is for all the DBAs to have their own
>> individual accounts on the system with their individual .k5login files,
>> plus all have access to the oracle account via .k5login.  Maybe it's a
>> failure of the imagination, but I don't see how any hash of one value
>> to one other value would work for that.  I think multiple values would
>> have to be allowed.

> Ah, I thought that you meant ``multiple principals are authorised
> to log on to a local account'', rather than ``a single principal
> can be authorised to log onto multiple local accounts''.

> No, a simple hash lookup can't do that.  I wasn't considering that
> case, but as you point out it is valid.

> But, I am not proposing that we remove the code for .k5login but
> rather we allow organisations to disable it if it is undesirable
> in their environment.

> I am also proposing that we put in a simple hash lookup because it would
> be quite useful in a number of situations.  This would meet my needs as
> I do not need to authorise a single principal to multiple accounts, but
> perhaps something a bit more flexible would be more desirable.

Right, I definitely agree with what you're proposing.  I was only meaning
to support Nicholas's use case as well and to mention that I don't think
what you're proposing entirely replaces the desirability of being able to
say that all .k5login files are found in, say, /etc/k5login/username.

But these are all potentially independent changes.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>