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

On Mon, Oct 24, 2011 at 6:19 PM, Harry Coin <[email protected]> wrote:
> On 10/24/2011 5:17 PM, Nico Williams wrote:
>> Now, can you clarify what it is you want?
>
> Sure.  I want everything that worked great here to continue as before (ldap,
> pam_krb5, nslcd, local software) -- except with -sec=krb5x kerberos benefits
> as advertised.  Specifically
>
> A)  without taboo against uid:uname:principal name combinations if I
> specifically indicate I permit them.
>
> and, as pre-kerberos,
>
> B) if a server should offer  N directories for remote access, but
> restricting each of them specifically to F(N) boxes, where F(N) < all the
> boxen in the realm, there exists at least one directory available to
> processes on  box Y but not Z, and likely too some on Z not available to Y.
>  then:
>
> Files written on the share by account-name:uid QQ on Y  will not be
> available to QQ if on Z.  Such files will appear with the QQ's correct
> uname:uid.  Should QQ write on Z, such files may not be visible if on Y, but
> will appear correctly named on Z.   If a process running as QQ exists on the
> server it will have access to both the files written from Y and from Z by
> user QQ.

I'm having a hard time parsing what you write.  But if I understand
correctly you want *per-share* mappings of principals to authorization
IDs.  That would require changes to the application -- changes to the
Kerberos library alone could not provide that feature.  (Note that
Solaris, for example, allows only per-share mapping options for
*root*, not any other local accounts.  What you're asking for, if I
understood correctly, is a fairly large, though perhaps desirable
change to NFS servers.)

Can you confirm?

But clearly that can't be it because when I read your patches I see
something completely different.

> C)   Unames map onto uids in a 1 to 1 way.   Unames map onto
> 'multi-application-use' kerberos principals in a 1 to 1 way.

What's a uname?  What's a "multi-application-use Kerberos principal"?

> Just as they all did before kerberos meets network wire integrity/privacy
> assurance.

Uh, NFS never had per-share mappings of anything other than UID 0
before it got kerberized.

> Except, now with the advertised kerberos ability to authenticate the user,
> or to provide integrity checks of the traffic, or to encrypt the trafffic
> entirely if asked.
>
> Being that it's all free instead of asking for a refund I wrote some patches
> that get it done.

Do the patches address your problem?  Can you characterize what the
patches do?  Or confirm my characterization?  Here's what I think your
patches do:

 - add a simple database for aname2lname mapping consisting of k5login
files named /etc/k5login.d/<username>; aname2lname() checks *all* of
these in dirent order!!

 - add an in-memory cache for aname2lname() and kuserok() results.

Is that a fair summary?

If so, the change to aname2lname is completely unacceptable.  Nor only
is it too slow (the cache won't help many apps), it's also
non-deterministic: if a principal appears in more than one file then
the result will depend on dirent order.  Plus any cache of any of this
would require a way to detect stale cache entries.

If you want a DB, well, I'll be adding a plugin for an aname2lname DB.
 And I'll probably include a default plugin that uses a binary search
on a sorted file where every line consists of <principal> <username>,
or something like that.

FYI, it helps to develop patches against the Heimdal git repository,
then port them to the FreeBSD tree.  It also helps to have an online
git repo that the rest of us can pull from.

Nico
--