Cross-filed as support case 01930265.

I filed this bug against RHEL7, but this affects all sssd-enabled distributions across the board (RHEL6, Fedora, et. al.).

Additionally, in case it wasn't clear, this bug also breaks the ability of non-Linux NFSv4 RPCSEC_GSS clients to interoperate with Linux NFSv4 RPCSEC_GSS servers.

Furthermore, just in case it's not clear, we specifically reject the assertion in sss_rpcidmapd(5), that the solution is to always enable use_fully_qualified_names. That is inadequate because:

1. Not enabling use_fully_qualified_names will result in the Linux NFSv4 client/server implementation violating RFC7530. This is not something sssd should enable under ANY circumstances, let alone by default.

2. In the case where only one domain is in use—which is the case for many sites—enabling use_fully_qualified_names adds needless overhead and pain.

From looking at the code, I think the easiest way to implement this is to modify sss_nfs_uid_to_name() and sss_nfs_gid_to_name() to scan the result of id_to_name() that was placed into (char *name). If a "@" character is found, then take no action; otherwise, append "@" + the (char *domain) argument that was passed to the function (which is currently unused).

Unfortunately, this will trigger another bug: if the administrator has enabled multiple domains in sssd without enabling use_fully_qualified_names, and id_to_name() finds a match in a domain different than the one being used as the "Domain" setting in the [General] section of /etc/idmapd.conf, then appending the char *domain argument will produce an incorrect result.

But even if use_fully_qualified_names were enabled, and the result were qualified with the matching domain, that domain would be different than the idmapd domain, so it would be nonsensical to return it.

The real issue is that all mappings the libnfsidmap sss.so plugin performs should be constrained to the NFSv4 idmap domain, but there appears to be no way to constrain id_to_name() to return results only for a specific domain.

Is there a function equivalent to id_to_name() that additionally takes a specific domain to search?

So far the only way to filter out certain by-ID requests from certain domains is to limit the ID ranges using the min_id/max_id parameters. Would that help your case?

At the moment, the by-ID requests cannot include a domain to search with in the wire protocol. It's something that could be added, potentially, but the current code doesn't allow it.

(In reply to Jakub Hrozek from comment #4)

> So far the only way to filter out certain by-ID requests from certain
> domains is to limit the ID ranges using the min_id/max_id parameters. Would
> that help your case?

It's not necessary for us: while we have multiple domains, each of our Linux hosts has one (and only one) domain enabled in sssd.conf.

So, in our particular environment, modifying the libnfsidmap sss.so plugin to append @domain to the reply from the SSS_NSS_GETPWUID/SSS_NSS_GETPWUID calls (if the reply lacked a domain due to use_fully_qualified_names not being enabled) would result in correct behavior.

But that doesn't solve the general case.

> At the moment, the by-ID requests cannot include a domain to search with in
> the wire protocol. It's something that could be added, potentially, but the
> current code doesn't allow it.

Alas, I reached the same conclusion after studying the code in more detail.

The problem here is that the libnfsidmap sss.so plugin needs to perform extremely specific functions:

1. 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.

2. 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.

The libnfsidmap sss.so plugin can perform #1 easily, as passing the user@domain to sssd's SSS_NSS_GETPWNAM function will ensure that the lookup is constrained to the domain in question. (Although the plugin doesn't check to make sure the @domain portion matches the Domain setting in /etc/idmapd.conf.)

But #2 is currently intractable, because sssd's SSS_NSS_GETPWUID call doesn't provide a mechanism to constrain the search to a specific domain. So if the host in question has multiple domains configured in sssd, and those domains have overlapping uid/gid ranges, then the libnfsidmap sss.so plugin can return incorrect results.

Compounding this is the issue that if use_fully_qualified_names isn't enabled, sssd will omit the @domain part of the returned lookup.  But appending the NFSv4 idmapd domain isn't safe, because the resulting name can't be guaranteed to actually be from that domain.

So, in conclusion, this means that the current implementation of the libnfsidmap sss.so plugin is faced with two options, both unpalatable:

1. Return non-compliant NFSv4 attribute objects lacking the @domain part, which will cause Linux NFSv4 RPCSEC_GSS clients/servers to violate RFC7530 and thus break interoperability with non-Linux-based NFSv4 RPCSEC_GSS clients/servers.

2. Return compliant (but potentially wrong) user@domain NFSv4 attribute objects.

The libnfsidmap sss.so plugin currently implements option #1, and upon reflection, I think this is probably the best choice: better to fail (which is how RFC7530-compliant clients/servers will interpret an attribute lacking the @domain part) than to potentially return incorrect results.

(All of the above applies to group/gid translation as well.)

The only way to truly solve this problem is to extend the sssd API with calls that will constrain id-based lookups to a specific domain. E.g., sssd needs SSS_NSS_GETPWUID_IN_DOMAIN and SSS_NSS_GETGRGID_IN_DOMAIN (for example) calls.

We're grateful for the libnfsidmap sss.so plugin, because without it, Linux NFSv4 RPCSEC_GSS clients/servers in heterogeneous environments wouldn't even be possible. And the limitations of the libnfsidmap sss.so plugin aren't anyone's fault—the sssd API was cooked before the libnfsidmap sss.so plugin was created, so its needs couldn't have easily been foreseen.

But without extending the sssd API, the libnfsidmap sss.so plugin cannot behave correctly for Linux NFSv4 RPCSEC_GSS clients/servers in heterogeneous environments. That is an important goal, so I would argue it is worthwhile to extend the sssd API to enable it, even if that code doesn't land in RHEL until 7.5, 7.6, or even 8.0.

Thank you for your detailed analysis.

JFYI, we are planning to offer and extended API for other use cases as well. I will started with a design page which should explain the new API. I'll try to cover the 'ID_IN_DOMAIN' case as well and will post a link here when the page is done. Feel free to ping me if this doesn't happen during the next 4 weeks.

bye,
Sumit

So far I reproposed the bug to 7.6, because the 7.5 development is quite full already. I'll also clone the bug upstream so that we track it in pagure as well.

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3535

(In reply to Sumit Bose from comment #6)
> Thank you for your detailed analysis.
> 
> JFYI, we are planning to offer and extended API for other use cases as well.
> I will started with a design page which should explain the new API. I'll try
> to cover the 'ID_IN_DOMAIN' case as well and will post a link here when the
> page is done. Feel free to ping me if this doesn't happen during the next 4
> weeks.
> 
> bye,
> Sumit

Hi Sumit. Did you have a chance to create the design page to resolve this issue? I am checking for updates at https://docs.pagure.org/SSSD.sssd/design_pages/index.html

This BZ has been evaluated multiple times over the last several years and
we assessed that it is a valuable request to keep in the backlog and
address it at some point in future. Time showed that we did not have such
capacity, nor have it now nor will have in the foreseeable future.

In such a situation keeping it in the backlog is misleading and setting the wrong
expectation that we will be able to address it. Unfortunately we will not.
To reflect this we are closing this BZ. If you disagree with the decision
please reopen or open a new support case and create a new BZ. However this
does not guarantee that the request will not be closed during the triage
as we are currently applying much more rigor to what we actually can
accomplish in the foreseeable future. Contributions and collaboration in
the upstream community and CentOS Stream is always welcome!

Thank you for understanding
Red Hat Enterprise Linux Identity Management Team