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

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.

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)).

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!

> Then we get into the whole 'taint' fiasco.    I just didn't want to patch

One thing at a time please!

> 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.  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
--