From nobody Thu Mar 28 13:13:00 2024 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4V53rH1my2z5FrGQ for ; Thu, 28 Mar 2024 13:13:19 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4V53rF6Pbjz4ZnL for ; Thu, 28 Mar 2024 13:13:17 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=ldeYuHn1; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2607:f8b0:4864:20::631 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1e0bec01232so8462885ad.3 for ; Thu, 28 Mar 2024 06:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711631596; x=1712236396; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=jM/rX+oHl3Y06QyALoLJCyCgmazLI8W69ADsl+a6kKA=; b=ldeYuHn1648z/4bZmZmfN7/C7aoBuy6B3SawlYxRf49e6hp6zVzOTnMwTA5BM1W2TY yzx4AoWbj+p2H8JsK0FFxwii44bVHw5FUwRBzPLfVyOgbTwIQn7t7XBRj/LhMADkcSJ+ DaPedAreD4YKQsB1liI8LpybqTSD3A2aDKWHlH0lGjrqfk4pGaiFiwwfr7QegHPDLYBS hmp547vN3oZylgCmnQBio+YIJlzfdrdu0x5HWXLVeVCRM/JYBfTLKZcsv70SUl28Yipq wVXlByjRoTYSatq39OJ4hrDgAceiHDyejqTA1sswMJKQRj1/qtfdFmNz3voDAeyNRO+v cZmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711631596; x=1712236396; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jM/rX+oHl3Y06QyALoLJCyCgmazLI8W69ADsl+a6kKA=; b=r3jElIMVNb5Yiegg5Ck6oOM9Jc/oKQ5SgNnQNULpnDxfPGC4h87AzyYBJjDM/mFrIW LPtMwzlvmDtgQLZMv+35KGsoeDJaom7j2Zw2MRo/4zm3vxydz/IkBsJMWr5olCrF4uyu Hpk+pUpjfcEb+D6xQ55mWJDcr9DLBF0HKQh7RB8JswjvnY8sKjqYg5PVNcXGDzoE9oCH sGYkxTdHhivPEdDdHhdIw3Q/9RUvG+uwp2tjwDcVuGx/6/c78hLhoEIAxvNhDq5dnz88 OlXNVnRWza7B4WKBANcBHAJsglUDVKxoB502EkKxu94fnSK/TA4aVbm48M10I/iZgBpQ 9Qdw== X-Gm-Message-State: AOJu0YwSHrfBh5QtKQwmejyfFpC3BDR5NmbSc2fLwLyqZ2AQ500xHMNZ vXUPJ17Xx3NBVxhfHIjflrvezFmPAO9l6T6kvuJ9+EJMw7Zksensw9m0+xiPGo5GkGXECkSOkxD HtFF/q7FXRDqeZOOdOVUAmdfWr3kR8P4= X-Google-Smtp-Source: AGHT+IF7HRiqwAYtSY+Fy1fWQxrTTbZJXcMGfyKDj+4nHvwYiIYfPWtNryGSdzcchnGJA6dI1z8ryzOTn5VRF3fhe4s= X-Received: by 2002:a17:902:dad1:b0:1e1:1791:3681 with SMTP id q17-20020a170902dad100b001e117913681mr2898296plx.61.1711631595792; Thu, 28 Mar 2024 06:13:15 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Thu, 28 Mar 2024 06:13:00 -0700 Message-ID: Subject: Re: Kerberised NFSv4 - everyone gets mapped to nobody on file access To: Andreas Kempe Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.61 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_SPAM_SHORT(0.39)[0.392]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TAGGED_FROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MISSING_XM_UA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; RCVD_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::631:from] X-Rspamd-Queue-Id: 4V53rF6Pbjz4ZnL On Thu, Mar 28, 2024 at 6:09=E2=80=AFAM Rick Macklem wrote: > > On Thu, Mar 28, 2024 at 3:46=E2=80=AFAM Andreas Kempe wrote: > > > > On Wed, Mar 27, 2024 at 03:20:03PM -0700, Rick Macklem wrote: > > > On Wed, Mar 27, 2024 at 10:17=E2=80=AFAM Andreas Kempe wrote: > > > > > > > > On Tue, Mar 26, 2024 at 05:54:38PM -0700, Rick Macklem wrote: > > > > > On Tue, Mar 26, 2024 at 5:33=E2=80=AFPM Rick Macklem 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, som= ething like: > > > > > # tcpdump -s 0 -w out.pcap host > > > > > 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 ch= aracters 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. I= t > > > > 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 cal= l > > > > made > > > > > > > > NFS 438 V4 Call (Reply In 131) Open OPEN DH: 0x30a4= c0aa/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: " if that says anything. > > > > > If you email me the pcap.out as an attachment, I'll look at it in wir= eshark. > > > The out.pcap should include both the Open that creates a file and an > > > "ls -l ", 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??? > > 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 wi= th 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 ar= e > > > > supposed to be. They are not the ASCII representation and nither my > > > > user's GID and UID that are both 0x7b02. > > > > > > > > // Andreas Kempe > > > > >