[Freeipa-users] IPA+AD trust and NFS nobody issue

[Alexander Bokovoy]

On Wed, 16 Jul 2014, Nordgren, Bryce L -FS wrote:
>
>
>> Thing is, nfsidmap always adds and then substracts '@' plus domain,
>> assuming that the part prior to '@' is what going to be mapped by the
>> domain-specific idmap mapper.
>
>That's the crux of the problem right there.  Sssd is not a
>domain-specific idmap mapper.  Sssd is a domain-aware, multidomain
>idmap mapper. Hence the first "@".
You are mixing different mappers and different layers.

SSSD uses separator (set to '@' by default and enforced as '@' in IPA
trusts mode) to automatically qualify users from non-primary domains. In
case of IPA trusts this is enforced for trusted domains of IPA domain
which are discovered automatically by IPA-specific means. SSSD, thus,
exposes these names as normal system-wide user and group names,
available to anyone performing NSS calls of the libc.

NFS idmap layer does own optimization by internally presenting any
NFS-provided name as name at domain and passing it to internal NFS idmap
providers. idmap plugins then take this name at domain and perform own
mapping. This has nothing to do with system-wide user names and it has
nothing to do with on wire NFS protocol, it is particular NFS idmap
library implementation detail. Note that libnfsidmap actually has two
stacks of idmap modules, applied separately to NFSv4 domain names and to
GSSAPI-authenticated names. While the same plugins are used in both
cases, the use of 'nsswitch' plugin for GSSAPI-authenticated names is
debatable without applying krb5_aname_to_localname() first, which
nfs-utils doesn't even do.

In other words, we have two different layers, dealing with different
conceptual idmap approaches, and one of them is being used by the other.
The latter (NFS idmap 'nsswitch' plugin) didn't expect that system-level
names might include the same symbol '@'. Given that the NFS
idmap-internal '@' is always appended to NFS-protocol provided name,
splitting the resulting string on last '@' is the right thing to do to
avoid clashes.

>
>> What you get here by not adding the '@' to
>> the name which contains '@' already is that wrong domain will be classified
>> and then wrong name is passed to the system to ask for.
>
>The corollary of not adding the '@' is not subtracting it either.
This would be a major change to NFS libnfsidmap library and while
technically could be superior, it serves little value in this context.

>If sssd is the system service that deals with multidomain issues, then
>let it. The NFS idmapper doesn't need to add or subtract the "@" and
>should pass it on to sssd, if it's interacting with sssd. One flag to
>the mapper ("domain-aware-system=true"), the internal linux only
>problems are solved internally, and the over the wire traffic is not
>broken in ways that break other clients (e.g., your patched system
>emits traffic which looks _exactly_ like the
>"traditional"-read-"conforming" NFS case to unpatched systems and other
>ground-up implementations). Breaking the protocol in a self-consistent
>way which excludes other platforms is a very Microsoft-like approach
>and makes me feel all dirty. Sometimes (not now) it's necessary as a
>band-aid/workaround, but this time the band-aid doesn't have to break
>things. :)
As I said, there is no protocol, on wire or between libnfsidmap and
lower OS levels, that requires special '@' handling. It is purely
internal thing to libnfsidmap. The way it was treated was wrong from the
beginning so I would argue the strrchr() fix is actually the proper fix
rather than band-aid.

>I'd say the real solution, long term, is to point both sssd and the nfs
>idmapper at something like a umich_ldap server managed by freeipa. This
>has additional benefits like centralizing the idmapping in a way that's
>exportable to foreign organizations so they can be clients to my
>servers, being able to resolve uidNumber collisions when I'm not in
>control of the AD I'm trying to use, supporting bare Kerberos trusts,
>allowing multiple GSSAuthNames (e.g., my AD account, Kerberos
>credentials from my home network KDC, my SAML account) to be recognized
>as the same user, etc. Room for growth.
We want to have specialized NFS idmap plugin to existing libnfsidmap
that uses specialized SSSD API internally (the patch is on review on
SSSD list, at least it was when I went to my vacation which I'm enjoying
now:). Alternatively, we want to write a complete replacement of
libnfsidmap given the knowledge we have at SSSD side.

What is lacking here is the fact that with krb5 1.13 we also have way to
dynamically plug into krb5_aname_to_localname() processing and get rid
of static auth_to_local rules in krb5.conf for whole IPA domain and its
trusted domains. In this scheme for GSSAPI-authenticated NFS names all
what is needed to be done is krb5_aname_to_localname() call prior to use
of 'nsswitch' plugin. The rest will be done by SSSD automatically and
for all applications, not only NFS idmapper.
-- 
/ Alexander Bokovoy