I would classify this as a 'security exploit' between the relationship of the Linux 'client' system(s) and FreeIPA. Though not necessarily a 'bug' it DOES expand the local root accounts ability beyond that of the local O/S instance (which it should 'not').
The repetitive statements that this issue is all about UNIX and how it works is incorrect. Though a 'root' account has the ability to create a localized version of any account ID and 'su' to it, the use of FreeIPA permits the local root account to obtain and access resources existing externally to the local instance (though specifically configured 'not' to be available to it).
That IS an issue with the FreeIPA implementation, permitting the local "root" account to escape its boundaries...
The short of it is that NFSv4 protocol relies a username being shared between the server and client, and not the UID/GID numbers (which were used in the earlier versions) and the UID <==> username mapping can actually be different on the client and the server.
As part of the NFSv4 protocol both the server need to map the common security contexts/permissions, owner and owner_group to something that makes sense for the local file-system operations. That mapping is done by IDMAPD on Linux systems.
On a Linux system many local file-systems operations are UID/GID based but those need to be translated to the shared NFSv4 context before they can be transmitted to the NFS server.
Maybe RFC 3530 can explain it better:
ยง 5.8. Interpreting owner and owner_group
The recommended attributes "owner"
and "owner_group"
(and also
users and groups within the "acl" attribute) are represented in
terms of a UTF-8 string. To avoid a representation that is tied to
a particular underlying implementation at the client or server, the
use of the UTF-8 string has been chosen. Note that section 6.1 of
[RFC2624] provides additional rationale. It is expected that the
client and server will have their own local representation of owner
and owner_group that is used for local storage or presentation to
the end user. Therefore, it is expected that when these attributes
are transferred between the client and server that the local
representation is translated to a syntax of the form
"user@dns_domain"
. This will allow for a client and server that do
not use the same local representation the ability to translate to a
common syntax that can be interpreted by both.
Edit in response to your imapd.conf.
You using a static mapping to local user. You probably want to map the NFSv4 identities to LDAP users, which probably should should happen by the nsswitch
option, but apparently is not. You could try to see what is happening by increasing the verbosity of the idmapd on the NFS server.
Alternatively configure idmapd to directly query your LDAP server. The exact syntax may depend on the version you're using, but the man page shows something along the lines of :
[General]
Verbosity = 0
Domain = domain.org
Local-Realms = DOMAIN.ORG,MY.DOMAIN.ORG,YOUR.DOMAIN.ORG
[Mapping]
Nobody-User = nfsnobody
Nobody-Group = nfsnobody
[Translation]
Method = umich_ldap,nsswitch
GSS-Methods = umich_ldap,static
[Static]
johndoe@OTHER.DOMAIN.ORG = johnny
[UMICH_SCHEMA]
LDAP_server = ldap.domain.org
LDAP_base = dc=org,dc=domain
Best Answer
I don't think there is any magic here: at some time you will have to ensure UID/GID uniqueness and alignment across all servers then including in LDAP. In case alignment is not achieved then you amy have unexpected permissions. How to achieve this?
Once aligned everywhere, as servers are configured to rely on LDAP (PAM and NSS), local accounts and groups are no more required and should be removed, IMHO.