Re: aname_to_locaname vs gssapi svc/host.domain.org@REALM

On 10/24/2011 10:56 PM, Nico Williams wrote:
> On Mon, Oct 24, 2011 at 10:36 PM, Harry Coin<[email protected]>  wrote:
>> On 10/24/2011 10:00 PM, Nico Williams wrote:
>>> I agree that aname2lname should have a DB option.
>> But that's only half an answer, kuserok has to accept what aname2lname
>> produces.
> Yes, of course.  If kuserok is called on a {principal, username} and
> the user doesn't have a k5login file (or whatever) then if aname2lname
> says that the principal's username is the given one, then return true.
>
> I didn't mention that because to me it goes without saying.  Ah, I
> see, Heimdal's doesn't do that, but MIT's does.  OK, I'm fine with
> fixing that (but I want to check with Love first).
>
>>>> The above is the state of things pre-kerberos.  The name
>>>> whatnot/box?.domain.com were chosen because gssapi wants them that way.
>>> No, the GSS-API does not "want" them that way.  That's your imagination :)
>>> Yes, you *can* use principal names of that form.  The GSS-API doesn't
>>> force you to.  And no GSS app that I know of forces you to use
>>> *client* principal names of that form (with the exception I've
>>> described before for root-equivalent access in the Solaris NFS
>>> server).
>> You do keep mentioning this.  sasl client and sasl server just do insist
>> otherwise.   Then there's the whole 'reverse ip' thing where apps want to
> You said GSS, now you say SASL.  I'm confused.

That's because I live where applications maintained by lots of people 
who have firm ideas, such as yourself,  that don't comport with one 
another in small ways discovered by we folk who are supposed to stack 
all the bricks into something that delivers value reveal.   nslcd likes  
Ldap, ldap likes sasl, sasl likes gssapi, gssapi likes kerberos.   If 
any one of those ice skaters falls down the whole chain is useless.  Oh, 
and ldap likes ssl.  Try to explain to nslcd whose /etc/passwd home 
directory is 'nonexistent' where 'user only' ldap.conf files should be 
found specifying the certificate locations for mutual authentication.  
(all occurs before kerberos even enters the scene).


>
> The GSS-API, I assure you, does not say anything about what kinds of
> principal names you *must* use.  It defines various name types, allows
> mechanisms and future generic specifications to define additional name
> types, and leaves it to applications to declare when to use what name
> types.
>
> SASL/GS1 (RFC4752) says (requires?) that servers are named using the
> GSS_C_NT_HOSTBASED name type.
>
> SASL/GS2 (RFC5801) says that servers are typically called using the
> GSS_C_NT_HOSTBASED name type, but doesn't require it.
>
> Neither says anything about client principal names.
>
>> confirm addresses and build principal names from service names and the
>> reverse dns.   I don't much want the service account user name to be
> Can you be more specific?  FYI, this weekend I pushed to Heimdal's
> master branch a feature that provides a local search-list alternative
> to DNS for hostname canonicalization, in case that's what you're
> referring to.
>
>> different than the service name than what appears before the / in the
>> principal name.   Sometimes I think the folk here forget somehow that
>> services generally own files, and it's a bad idea for them to all be root.
> No, no, you're confused.
>
> The service part of host-based service naming was *never* intended to
> be a reference to Unix usernames or anything of the sort!  It was
> intended to be a reference to service names from the IANA port
> registry (i.e., what you expect to see in services(4)).

Yes, I do know this.  Somehow the folk who craft these services are 
given to creating for them local user accounts with the same name for 
the implementing daemons to use.  ldap (okay, slapd, go figure).  
nslcd,  nfs, etc.   We who don't author everything on our boxen have to 
go with the flow.

>
> The only case of principal naming where there's a hostname component
> and a username component, that I know of in *widespread* use is the
> Solaris NFS server's root/hostname convention for root-equivalent
> access.
>
> Anyone can add additional naming conventions, but they should really
> not add any more<username>/<hostname>  conventions.  It's bad enough
> that we have the Solaris one that *conflicts* with the standard
> host0based service naming!
>
> If you want user/host-based naming then let's go for something like
> <hostname>/<username>  or "user"/<username>/<hostname>  or something
> along those lines, something unambiguously not conflicting with
> host-based service naming!

I do appreciate how it is you think I have the ability to implement 
those choices.   You are aware I trust that without the patches I wrote 
no principal with even one / in the list can write a file over a network 
share, much less the two you've written above?

>> Then we get into the whole 'taint' fiasco.    I just didn't want to patch
> One thing at a time please!

For me it's all the same thing-- krb5, and what I need to do to not 
break anything that works, while adding what I need so I can secure the 
wire whether or not the principal has a / in it.

>> the library in the way Rune suggested as I didn't want to alter any current
>> behavior.   My changes don't alter any current behavior, (other than failing
>> on the /, and making kerberos an option to authenticate local users with no
>> default home directories).  Whether they're the right thing forever, well
>> I'll let people for whom heimdal is front and center everyday worry about
>> that.
>>
>> [...]
> I'm skipping some parts of your reply because it's getting long.
>
>>> Not acceptable.  Use a real DB, not a directory of k5login files
>>> searched in dirent order.  I'm irrevocably opposed to
>>> non-deterministic aname2lname behavior.
>> It's deterministic if the editor of the /etc/k5login.d directory doesn't do
>> anything that when they look at it would appear senseless anyhow.  I'm sure
>> someone could write a little test to validate that no principal matches more
>> than one username in /etc/k5login.d  (note it does not check the user's home
>> directories.   This adds functionality actually since it's possible with
>> this for admins to block the ability of a user to affect the behavior of
>> root enabled daemons reading ~/.k5login files.
> It's not deterministic.

Well, in the real world lets just say that the upper bound of worst case 
compute time is so low the variability isn't something worth sweating 
over too much.   The only entries in /etc/k5login.d are going to be a 
couple of lines for each of the accounts without home directories in the 
/etc/passwd file.   Don't let lack of perfect stop you from accepting good.


>   Besides, not all filesystems have
> deterministic dirent order (it used to be that if all you did was add
> files then they always went at the end of the directory, but for
> filesystems like ZFS you can't even rely on that, but even older
> filesystems stop being deterministic after enough changes including
> deletions).
>
>>> By using a DB (Berkeley DB2, 3, 4, SQLite3, cdb, a flat text sorted
>>> file, ...) you avoid the need for a cache, and you avoid the
>>> non-deterministic behavior.
>> There's no point in bringing a tractor to a move a pea.
> Then use a sorted, flat-text file then, and binary search it
> (searching for non-quoted newlines whenever you take a fork in the
> tree).  I guarantee you that will perform better than your directory
> scheme, and it will be deterministic.
>
> Nico
> --
>