Re: Behavioural differences in Heimdal and MIT [was: Re: API differences between Heimdal and MIT]

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

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  
>> process
>> *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  
> that,
> 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  
> care
> about the initial access() check, but if people want to change  
> Heimdal's
> behavior it's worth having the alternatives precisely spelled out  
> (which
> 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