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

On Wed, Oct 12, 2011 at 3:29 AM,  <[email protected]> wrote:
> On Wed, Oct 12, 2011 at 09:44:57AM +0200, [email protected] wrote:
>> There are two mapping daemons involved, at the server (local uids <-> strings)
>> and at the client (strings <-> local uids) according to passwd.
>
> Note that for authorization purposes NFSv4 server maps the principal names
> (which are the authenticated identities) to local account names without
> any extra modification. Then this string is mapped to the server-local
> numerical uid and its access rights are applied.

It's... more complicated.  Or should be, soon enough (because soon
enough I expect servers to support the PAC).

> I am not aware of a way (or the developers' intentions) to be able to
> specify any extra mappings, like "root/*" to "root". If there is any
> code which suggests otherwise it is most probably a mistake - this
> would have long reaching security implications.

Well, see my descriptions of what Solaris does.

> A more general principal-mapping layer might be useful in NFSv4 but I
> am unaware of its existence. In any case such mapping does not belong
> to Kerberos nor to Kerberos naming standards as it would be a matter of
> site-local policies.

For principal to user mapping MIT has a very configurable rule
language for aname2lname, and dormant support for using a DB.  And it
could be extended further.  IMO Heimdal needs something like it (and,
indeed, I have patches for supporting the same aname2lname DB feature
as MIT).

For user/group name in NFSv4 on-the-wire form (name@domain), the
mapping is really a very local issue, though it can be shared across
multiple machines with the right facility.  Solaris supports several
mapping schemes, including one that can map arbitrary SIDs to
UIDs/GIDs on demand, so it can be done.  Samba has a different
solution that also works.  See also
http://tools.ietf.org/html/draft-adamson-nfsv4-multi-domain-access-04

Nico
--