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

[Alexander Bokovoy]

On Wed, 16 Jul 2014, Nordgren, Bryce L -FS wrote:
>> Hi Aron,
>>
>> the support case you referenced is linked to bugzilla
>> https://bugzilla.redhat.com/show_bug.cgi?id=1066153 which is fully acked
>> for RHEL-6.6, the state of the bugzilla is ON_QA, so currently it looks the
>> patch will be released in 6.6..
>
>username at domain is coded in the NFS spec as an NFS id which goes over
>the wire. It's unclear what allowing two "@" signs means (which "@"
>separates username from doman, and which is part of one of these
>components?) While I'm sure this patch is trivial and I'm certain the
>patch works, it breaks interoperability with everything not running the
>patch (all non-linux and any non RHEL/Centos 6.6 linux). This is
>probably acceptable in certain closed environments, but I can never use
>it here.
The patch went upstream already. What it does is changing lookup at
last '@' instead of the first one. For traditional NFS cases it changes
nothing as there is one '@' anyway, the one added by nfsidmap code.


>However, patching the idmapper so that if the username already contains
>an "@", it doesn't add another one should also be trivial and should
>also work. It has the added benefit of not trashing interoperability.
>Conceptually, it allows sssd to convey both username and domain with no
>extra overhead and upgrades the linux nfs idmapper to handle living on
>a system which understands more than a flat namespace. To do it right,
>sssd always needs to supply the nfs idmapper usernames of the form
>"username at domain" regardless of the regex used to parse out those
>components at the login prompt.
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. 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.

Current implementation (with the patch) survives both cases better than
what you propose.

-- 
/ Alexander Bokovoy