TL;DR: omitting the @domain part of NFSv4 attribute values when
use_fully_qualified_names is false is a clear violation of RFC7530, and breaks
the ability of Linux NFSv4 RPCSEC_GSS clients to interoperate with non-Linux
NFSv4 RPCSEC_GSS servers.

Description of problem:

Currently, when the libnfsidmap sss.so plugin maps uids/gids to NFSv4 attribute
values (for use with the RPCSEC_GSS NFSv4 security mechanisms), it looks to the
value of the use_fully_qualified_names sssd.conf configuration option to decide
whether to generate fully-qualified user@domain attribute values, or whether to
omit the "@domain" component of the attribute value.

We can clearly see this by looking at the result of what a RHEL7 NFSv4 client
sends to server when calling chown on a nfsvers=4.1,sec=krb5 mount, when
use_fully_qualified_names is set to "false" (the default) in sssd.conf for the
example.org domain:

Network File System, Ops(4): SEQUENCE, PUTFH, SETATTR, GETATTR
    [Program Version: 4]
    [V4 Procedure: COMPOUND (1)]
    Tag: <EMPTY>
    minorversion: 1
    Operations (count: 4): SEQUENCE, PUTFH, SETATTR, GETATTR
        Opcode: SEQUENCE (53)
        Opcode: PUTFH (22)
        Opcode: SETATTR (34)
            stateid
            Attr mask: 0x00000010 (OWNER)
                reco_attr: OWNER (36)
                    fattr4_owner: testuser
                        length: 8
                        contents: testuser
        Opcode: GETATTR (9)
    [Main Opcode: SETATTR (34)]

Note that the fattr4_owner field is the bare username, with the @example.org
domain.

If we set use_fully_qualified_names to "true" in sssd.conf for the example.org
domain, the libnfsidmap sss.so plugin correctly qualifies the username with the
@example.org domain:

Network File System, Ops(4): SEQUENCE, PUTFH, SETATTR, GETATTR
    [Program Version: 4]
    [V4 Procedure: COMPOUND (1)]
    Tag: <EMPTY>
    minorversion: 1
    Operations (count: 4): SEQUENCE, PUTFH, SETATTR, GETATTR
        Opcode: SEQUENCE (53)
        Opcode: PUTFH (22)
        Opcode: SETATTR (34)
            stateid
            Attr mask: 0x00000010 (OWNER)
                reco_attr: OWNER (36)
                    fattr4_owner: testuser@example.org
                        length: 20
                        contents: testuser@example.org
                        fill bytes: opaque data
        Opcode: GETATTR (9)
    [Main Opcode: SETATTR (34)]

The problem here is that the libnfsidmap sss.so plugin MUST NOT omit the
@domain component when mapping uids/gids to NFSv4 attribute values, because
this is clear violation of RFC7530.  RFC7530?5.9 states:

"In the case where there is no translation available to the client or server,
the attribute value will be constructed without the "@". Therefore, the absence
of the "@" from the owner or owner_group attribute signifies that no
translation was available at the sender and that the receiver of the attribute
should not use that string as a basis for translation into its own internal
format. Even though the attribute value cannot be translated, it may still be
useful. In the case of a client, the attribute string may be used for local
display of ownership."

In other words, an attribute value without the "@domain" component does NOT
mean "use the default domain for translation"; it explicitly means "reject this
attribute".

We didn't see this breakage when we were using a RHEL7 NFSv4 RPCSEC_GSS client
with a RHEL7 NFSv4 RPCSEC_GSS server, because on the server, the libnfsidmap
sss.so plugin cheerfully interprets the bare username as being in the default
domain, instead of obeying RFC7530 and rejecting it. So, because both RHEL7
NFSv4 RPCSEC_GSS clients and servers do the wrong thing, they can interoperate,
because they do the wrong thing consistently.

But we are now attempting to use RHEL7 NFSv4 RPCSEC_GSS clients with a
non-Linux NFSv4 RPCSEC_GSS server that properly obeys RFC7530 and rejects
attribute values without the @domain component. Against such a compliant
server, a RHEL7 NFSv4 RPCSEC_GSS client cannot manipulate any user/group
attribute values. This is a complete showstopper for us.

(Setting use_fully_qualified_names = true isn't an acceptable workaround for
us, as this would cause a huge, user-visible impact to our enterprise
environment.)

The fix for this is to update the libnfsidmap sss.so plugin code to always map
uids/gids to fully-qualified name@domain values, regardless of the value of the
use_fully_qualified_names option in the sssd.conf file.

Unfortunately, for mapping names to uids/gids, I would argue that the
libnfsidmap sss.so plugin code should continue to default unqualified names to
the default domain, even though that is a violation of RFC7530, in order not to
break older clients that haven't updated.

Version-Release number of selected component (if applicable):

sssd-common-1.15.2-50.el7