Please forgive my replying to myself, but -- after a rather unfortunate loss of the SSD my test VM's were on -- I'm recreating my test environments... **And the nfs ACE's are coming across as "user/at/domain" instead of just "user."** ("/at/" used because Outlook insists on trying to turn it into a "mailto" link even in "plain text" messages.)
Unfortunately it's physically impossible to get to the data on the old SSD, so I can't compare the settings to see what I did differently or wrong. I know I'm not the only person/organization that has this happen, because I have a rather-large (as in "strategically important to company") client who hit the issue as I was experimenting with this to reproduce a *different* issue.
If this isn't the right list, can someone please point me to the right one? I only see the one list on the majordomo page.
-----Original Message-----
From: Brian Cowan <brian.cowan@xxxxxxx>
Sent: Friday, July 8, 2022 4:39 PM
To: linux-nfs@xxxxxxxxxxxxxxx
Subject: Any way to make the NFS server ALWAYS report its NFS domain name when returning an ACL?
[CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.]
Hi all, Long time since I wasn't a lurker here...
After some serious google-whacking, I managed to get a RHEL 8.6 NFS server to return NFSv4 ACL's for files where the entries were names and not numbers... It feels a little kludgy to me to create a script to set the nfsd options in /etc/modprobe.d... But anyways...
The issue I'm currently dealing with is that -- at least for hosts in the same "nfs domain" (same Domain in idmapd.conf, and using the same AD domain via sssd) -- nfs4_getfacl reports bare names in the ACL entries. For example:
--------------------------------
[vobadm@vv-30-rh85 ~]$ nfs4_getfacl /net/bc-rh86-nfs/export/nfs/vobstore/siddumptest-rep.vbs/s/sdft/3c/13/2-0f41817b67fc11ec84e2525400c90287-t7
# file: /net/bc-rh86-nfs/export/nfs/vobstore/siddumptest-rep.vbs/s/sdft/3c/13/2-0f41817b67fc11ec84e2525400c90287-t7
A::OWNER@:rtTcCy
A::a.human.user:rtcy
A::vobadm:rtcy
A::GROUP@:rtcy
A:g:ccusers:rtcy
A:g:asdf_0:rtcy
A::EVERYONE@:rtcy
--------------------------------
The problem is, the application that is verifying the NFS4 ACL against permissions stored in a database (Yes, it's still ClearCase, and ClearCase is still around) is written assuming that the above output reads like this:
--------------------------------
[vobadm@vv-30-rh85 ~]$ nfs4_getfacl /net/bc-rh86-nfs/export/nfs/vobstore/siddumptest-rep.vbs/s/sdft/3c/13/2-0f41817b67fc11ec84e2525400c90287-t7
# file: /net/bc-rh86-nfs/export/nfs/vobstore/siddumptest-rep.vbs/s/sdft/3c/13/2-0f41817b67fc11ec84e2525400c90287-t7
A::OWNER@:rtTcCy
A::a.human.user@swtest.local:rtcy
A::vobadm@swtest.local:rtcy
A::GROUP@:rtcy
A:g:ccusers@swtest.local:rtcy
A:g:asdf_0@swtest.local:rtcy
A::EVERYONE@:rtcy
--------------------------------
Getting to this point was something of a long road involving building instrumented code to tell me something other than "no, I don't like the ACL..."
The file in question looks like this on the NFS server:
[testuser@bc-rh86-nfs ~]$ getfacl /export/nfs/vobstore/siddumptest-rep.vbs/s/sdft/3c/13/2-0f41817b67fc11ec84e2525400c90287-t7
getfacl: Removing leading '/' from absolute path names # file: export/nfs/vobstore/siddumptest-rep.vbs/s/sdft/3c/13/2-0f41817b67fc11ec84e2525400c90287-t7
# owner: vobadm
# group: asdf_0
user::r--
user:a.human.user:r--
user:vobadm:r--
group::r--
group:ccusers:r--
group:asdf_0:r--
mask::r--
other::r--
Is it possible to make the NFS server host always report the NFS domain name in response to this request? Because if there is, it's either well hidden or I'm having my usual issues with stuff staring me in the face...
Thanks in advance
Brian
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________
