Re: Kerberised NFSv4 - everyone gets mapped to nobody on file access

On Thu, Mar 28, 2024 at 06:13:00AM -0700, Rick Macklem wrote:
> On Thu, Mar 28, 2024 at 6:09 AM Rick Macklem <rick.macklem@gmail.com> wrote:
> >
> > On Thu, Mar 28, 2024 at 3:46 AM Andreas Kempe <kempe@lysator.liu.se> wrote:
> > >
> > > On Wed, Mar 27, 2024 at 03:20:03PM -0700, Rick Macklem wrote:
> > > > On Wed, Mar 27, 2024 at 10:17 AM Andreas Kempe <kempe@lysator.liu.se> wrote:
> > > > >
> > > > > On Tue, Mar 26, 2024 at 05:54:38PM -0700, Rick Macklem wrote:
> > > > > > On Tue, Mar 26, 2024 at 5:33 PM Rick Macklem <rick.macklem@gmail.com> wrote:
> > > > > > >
> > > > > > > Take a look at a packet capture in wireshark.
> > > > > > > Check that the @domain part of Owner and Owner_group attributes are
> > > > > > > the same and it is not a string of digits.
> > > > > > Oh, and just fyi, you can use tcpdump to capture the packets, something like:
> > > > > > # tcpdump -s 0 -w out.pcap host <nfs-server>
> > > > > > and then you can look at out.pcap whereever it is convenient to
> > > > > > install wireshark.
> > > > > > (I run it on this windows laptop.)
> > > > > > Don't bother to try and look at NFS with tcpdump. It doesn't know how
> > > > > > to decode it.
> > > > > >
> > > > > > > If the domain is not the same, you can use the -domain command line option
> > > > > > > on nfsuserd to set it.
> > > > > > > (Since this "domain" is underdefined, I'd suggest only ascii characters and
> > > > > > > all alphabetics in lower case.)
> > > > > > > If the client sends a string of digits, check to make sure the sysctl
> > > > > > > vfs.nfs.enable_uidtostring is set to 0.
> > > > > > >
> > > > >
> > > > > I'm using lysator.liu.se as the domain on both client and server. It
> > > > > seems to work since listing files give correct owners.
> > > > >
> > > > > I have dumped the traffic from mounting and creating a file named
> > > > > test file that shows up as owned by nobody. I get the following call
> > > > > made
> > > > >
> > > > >         NFS     438     V4 Call (Reply In 131) Open OPEN DH: 0x30a4c0aa/testfil
> > > > >
> > > > > In the OPEN (18) opcode, owner is set to
> > > > >
> > > > >                 0000   af 16 00 00 93 fc 00 00 07 76 0d 00
> > > > >
> > > > > while the server sets owner to ex. kempe@lysator.liu.se as expected
> > > > > when directory listings are made.
> > > > Doesn't make sense. What does wireshake show you for the Owner
> > > > attribute in the setable attributes of the Open arguments. It should flag
> > > > it as non-UTF8.
> > > >
> > >
> > > I'm afraid I don't really understand how to check this. Wireshark
> > > secifies "owner: <DATA>" if that says anything.
> > >
> > > > If you email me the pcap.out as an attachment, I'll look at it in wireshark.
> > > > The out.pcap should include both the Open that creates a file and an
> > > > "ls -l <file>", so there is a Getattr for the file as well.
> > > >
> > >
> > > I'll send you a capture off-list. Thank you for helping!
> > I looked at the capture. The server is definitely replying
> > "nobody@lysator.liu.se"
> > for both owner and owner_group for the file. You can see it in the
> > reply to Open, Lookup and
> > the Getattr (you need to go down past where it lists the attributes to
> > see what their
> > values are). It does know kempe@lysator.liu.se, since that is reported
> > for owner for the directory.
> Just to clarify, when you look at the replies you will first see a list of
> attribute names (those just indicate which bits were set for the attributes),
> then after that there is a list of attributes and their values.
> (At least that is what I see when I use wireshark. I don't think I toggled
> any setting to get that, but??)
> 
> rick
> 
> >
> > I have no idea why it would do that, but it's a Linux server so???
> >

Did you have a look at the owner field in the open reqest that created
the file? To me, it looks very strange. Could it be that the client
isn't sending a correct owner in the creation request, causing the
server to map it to nobody?

> > rick
> > >
> > > > rick
> > > > ps: If that is what is in the Owner field, all I can suggest is that was what
> > > >       a getpwnam() returned on the client. Possibly some weirdness with LDAP.
> > > >       (I never use LDAP. Only a local /etc/passwd.)
> > > >
> > > > >
> > > > > vfs.nfs.enable_uidtostring is 0 on the client machine and I am not
> > > > > quite able to make sense of what the 12 bytes in the owner field are
> > > > > supposed to be. They are not the ASCII representation and nither my
> > > > > user's GID and UID that are both 0x7b02.
> > > > >
> > > > > // Andreas Kempe
> > > >
> > >
>