[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Behavioural differences in Heimdal and MIT [was: Re: API differences between Heimdal and MIT]
I think goal is to make it *possible* to prevent the default
principal from logging in to a specific account.
Server is in realm A. User smith@A and smith@B both exist and are
different people. You want to be able to create an account for
smith@B on the server in realm A, but not grant access to smith@A.
Does this help the discussion any?
The AFS token-not-yet-available issues are just another example of
the same old problem we've always had with getting OS's to deal
properly with AFS.
On Feb 13, 2006, at 1:39 PM, Buck Huppmann wrote:
> On Thu, Feb 02, 2006 at 06:18:13PM +0200, Juha J. wrote:
>> You missed the point. If .k5login is *missing* there is no harm done,
>> "if(ret != ENOENT)" takes care of that. BUT if the authenticating
>> *cannot access* the .k5login (ret==EACCES), MIT goes to check if
>> the user
>> is trying to log in as oneself, whereas Heimdal treats this as if
>> the user
>> was not listed in .k5login and does not call match_local_principals
> more precisely, (from consulting the source, i admit) it appears that
> MIT applies the default mapping only if access(.., F_OK) != 0, but
> otherwise, if (subsequent to the access() check) opening the file for
> reading fails for any reason, it returns FALSE
> i gather, in the case of your AFS home directories, you mostly just
> about the initial access() check, but if people want to change
> behavior it's worth having the alternatives precisely spelled out
> means somebody besides me should probably confirm this and any
> other sub-
> tleties of MIT's implementation and don't listen to me)
> p.s.--apologies for having to abbreviate your surname, but my system
> (the way i have it configured) can't handle some of the characters--
> at least not displaying them