Closed sssd-bot closed 9 months ago
Dear Contributor/User,
Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.
After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.
We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.
Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.
Best regards, André Boscatto
CC: @tscherf
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3535
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1491030
Comments
Comment from jhrozek at 2017-10-04 21:32:33
Metadata Update from @jhrozek:
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 theDomain
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 theDomain
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, becauseSSS_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
@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 seeuser@DOMAIN
andgroup@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?