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

I completely agree that there are real reasons to want what we might
call "host-based usernames" -- indeed, I've had reason to want that in
the past.  In a prior life as a sysadmin I played with a
three-component naming convention where one component was a username,
one was a hostname, and the other was a constant string present only
to disambiguate from host-based service names.

The reason is as you describe: to provide isolation between system
user accounts on different hosts accessing common services.

In practice the simplest approach is to *avoid* this altogether by not
having system user accounts need NFS services.

The next simplest is to use "host-based usernames".  MIT krb5 makes it
easy to map these to whatever server-side usernames you want, but
since that means having either distinct usernames on the server for
each host instance of the same client-side username, that gets
complicated pretty quickly.  That's where share-level ACLs come in for
you: to avoid having to have so many server-side user accounts for
isolation, instead relying on share-level ACLs for the same.

But you have to understand that the NFS server feature that you want
(share-level ACLs based on client principal names) is non-existent.
Nothing in libkrb5 can make it come into existence.

Also, NFS will not be the only such application that you care about.
There will be others.

This is why the simplest solution is to avoid the problem at all costs.

A better solution would be to change the identity/authorization model
on the server.

Imagine that cred_t (the structure that holds a process/thread's UIDs
and GIDs in *BSD, Solaris, and now even Linux, though there it's
called struct cred *) has not just UIDs and GIDs, but possibly many
other things, including, say, a "label".  Here, by "label" I refer to
the concept from MAC (mandatory access control).  There are many types
of MAC but for the sake of simplicity I'll use SMACK (a Linux project)
where each label is distinct from all others and a simple rule
database allows some labels to access others.

So imagine that you have a label named after each client host.  Now
you could make sure that all username/client.hostname names map to the
same user account (and UID and GIDs) but *different* labels on the
server.  And the filesystem on the server stores labels for files too.
 So the files created by foo/client1 cannot be accessed by foo/client2
even though both have the same UID *unless* the SMACK rules database
specifically grants processes labeled "client2" label access to
resources labeled "client1".

Labeled security is truly the best solution for you, if you really
can't avoid the problem in the first place.

There are other labeled security systems that could help you, such as
MLS and DTE.  But the main thing is that with MAC labeling you get to
add isolation without having to explode your identity namespace.

Now, if you have an NFS client and server that support RPCSEC_GSSv3,
then you don't even need "host-based usernames" in order to implement
the labeled security solution, because with RPCSEC_GSSv3 you can just
have one host-based service client credential for *all* system
accounts on that client.  This would work because RPCSEC_GSSv3 is
specifically designed so that:

1) all contexts authenticate either or both of (bound) the client and a user
2) the client can assert facts about the client process' credentials
in the form of:
    - names of effective users and groups listed in that credential
    - names of privileges in effect for that credential
    - names of labels in effect for that credential
3) and the server gets to derive a server-side process credentials
from a) the authenticated identity(ies) (including any PACs delivered
by authentication), b) the asserted credential, c) any additional
context-specific limits to what credential elements the server is
willing to  grant to the given authenticated IDs.

The server was always able to do (3), but never on the basis of *two*
authenticated identities nor on the basis of any assertions made by
the client (since RPCSEC_GSSv1/2 never had either of these features).

Before Kerberized NFS we had AUTH_SYS.  AUTH_SYS is premised on the
client asserting the process credentials.  RPCSEC_GSSv1 (which forms
the basis for Kerberized NFS) had no concept of asserted credentials.
But even with AUTH_SYS actual NFS servers never had a feature to map
any asserted UIDs/GIDs other than 0 to anything different from what
was actually asserted, nor did most have a labeled security system.

You'll be glad to know that there are efforts to add labeled security
to NFS.  There's two aspects to labeled security in NFS: 1)
RPCSEC_GSSv3, 2) extensions to NFSv4 to support getting/setting object
(files, directories) labels.

So, I finally understand you.  I'm sorry it's taken so much effort on
your part.  And now you see that what you want is not currently easy
to achieve.  There's a lot of pieces missing.  Some implementors are
working on them, which is a the one bit of good news that I can give
you.

Nico
--