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@domain and passing it to internal NFS idmap providers. idmap plugins then take this name@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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
