libnfsidmap sss.so plugin MUST always use fully qualified names

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3535

Created at 2017-10-04 21:32:32 by jhrozek
Assigned to nobody
Associated bugzillas
- https://bugzilla.redhat.com/show_bug.cgi?id=1491030

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1491030

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

Comments

Comment from jhrozek at 2017-10-04 21:32:33

Metadata Update from @jhrozek:

Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1491030

Comment from ralston at 2017-10-04 22:14:50

The problem here is that the sssd API doesn't provide enough functionality for the libnfsidmap sss.so plugin to perform the specific tasks it needs to perform, which are:

Translate a user@domain NFSv4 attribute to a uid, where the @domain part must match the Domain setting in /etc/idmapd.conf, and the translation must be restricted to that domain.
Translate a uid to a user@domain NFSv4 attribute, where the @domain part must match the Domain setting in /etc/idmapd.conf, and the translation must be restricted to that domain.
Do #1 and #2 for groups and gids.

While SSS_NSS_GETPWNAM provides a way to perform #1, there is no sssd API call that will perform #2, because SSS_NSS_GETPWUID doesn't provide a mechanism to constrain the search to a specific domain.

The only way to resolve this is to extend the sssd API to provide the specific functionality that the libnfsidmap sss.so plugin needs.

Comment from jockesssd at 2017-11-06 06:14:16

Any idea if this bug will hit the use of Net App: http://www.netapp.com/us/index.aspx ? We will get one of their disks soon and we need to NFS export shares to serve our Linux clients.

Comment from ralston at 2018-02-28 23:59:36

Any idea if this bug will hit the use of Net App: http://www.netapp.com/us/index.aspx ? We will get one of their disks soon and we need to NFS export shares to serve our Linux clients.

@jockesssd Yes, you will see this issue with NepApp appliances, as NetApp follows RFC7530.

Comment from jockesssd at 2018-03-01 15:41:38

Luckily we have not deployed NetApp here yet but probably soon. What would a quick&dirty fix be for just one domain?

Comment from ralston at 2018-05-03 01:36:01

@jockesssd If you only have a single domain, setting use_fully_qualified_names = true will work around this issue. But it will be annoying to see user@DOMAIN and group@DOMAIN syntax everywhere where typically only bare users/groups are expected (e.g., in directory listings).

@jhrozek, @sbose: I'm guessing this issue has been pushed down in priority by other higher-priority issues? Because I don't see any discussion of the proposed new API here:

https://docs.pagure.org/SSSD.sssd/design_pages/index.html

There is the "Enhanced NSS (Name Service Switch) API":

https://docs.pagure.org/SSSD.sssd/design_pages/enhanced_nss_api.html

…but that doesn't look to be this feature.

Comment from jockesssd at 2018-05-11 13:23:11

@ralston , use_fully_qualified_names = true will not fly, users will be unhappy/confused. I was looking for a hack to hardcode the DOMAIN for NFS requests somewhere until this error has been fixed properly.

Comment from jockesssd at 2018-05-17 00:12:30

did a quick test using tcpdump to capture the nfs req. and for me I see the fattr4_owner attribute WITH domain, looks like your example above: fattr4_owner: testuser@example.org How did that happen? This was linux NFS client and server, do I need the real NetApp server to notice the error?

SSSD / sssd

libnfsidmap sss.so plugin MUST always use fully qualified names #4561

Comments