From nobody Sat Mar 30 23:01:50 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 4V6Xph1nrtz5GDsj for ; Sat, 30 Mar 2024 23:02:04 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 4V6Xpg6mJzz520P for ; Sat, 30 Mar 2024 23:02:03 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-2a20c054811so1874693a91.3 for ; Sat, 30 Mar 2024 16:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711839722; x=1712444522; 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=Z6ozNCKKNFVi/32BXClmjlA9ipEnoQZR7fPFzefibaw=; b=QVwjJ2gHPG36Jmq9+p5vN0sHXMzuvDKGTbHb67klfSvi2gYAiI/ZYowf4VMR9ZuhCV tSJZnRY4DXk4CTWNNh3iPENgYrPNUgvseVnb3eaFMzGHN+VL038SlO6OJEtYQZG4kGul 0UF5SK8ARK77uHkj3b6xttSF1I7ySUaBzg0umEbM76Drp1uIkl/9Xb7Leqe6uWZeOtqb o/L6kEm1PEpsGnCCutDabpI6657gdBK/vVWFsNWPiF75W2kB95ib0EN+KhbmAobgMs91 zcqwjnP/ZnK7IiLvc9Zc90o+88pxH4HVYPZF3xyFg0cRe2CfSazKQMOPpsS0Amwy/AL2 w0vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711839722; x=1712444522; 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=Z6ozNCKKNFVi/32BXClmjlA9ipEnoQZR7fPFzefibaw=; b=vEG0SPMBUxRyzjGd9acNzJfsTqg5qjJnan5p2YtV+p6WD2+zy83THZn22z16LWyM1f z7vaqMlpOjN34uiyPVzUKk+J91QxAiCgrTEK0iYgPkq96l5WoyxlTn+bltq3v2ulc7Dd fyb2TaKjnMabeT75cWASedTh5Qm+5xsAHfpKlpLwCNh40tAqO31spLudUlj2Tywjc5+o gNmZiIH8rzmPfXjH48s1hntxn53OVA/OK6uaZp3HyhFMqTWogSyI8+7Rl/SM4r0/8/Od 3c9ZpEoPdliW8d19sYN4OkXU+lCu94bQfGULyEJI6tkfHFOmn28dDubdsQy1HVcX9HWq uSTA== X-Gm-Message-State: AOJu0Yx7sM6m1t7wSbAv3oj6PQc2191rcDL+UKRTyX796mkoOwz54FiF RrBvzgqIGAp+DtTvKfNNxb737Bp7mhQyLD1lwc5FatQ9EgPU/fh7RzrstwiZoRiuVSHK2MW6gmi 2iUAadS2e7n5X/8avUyT6xZ9EOrb0LHI= X-Google-Smtp-Source: AGHT+IHQ6HJIPOmxFGpGSitPDfZFhInqN7sDAdhl501Z8ZOppFyK3Yk5hSscRCO9XF/kxvmYRRGY8q9DWgPsMBVt2zs= X-Received: by 2002:a17:90b:2386:b0:2a2:209b:afe0 with SMTP id mr6-20020a17090b238600b002a2209bafe0mr3284634pjb.23.1711839721662; Sat, 30 Mar 2024 16:02:01 -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: Sat, 30 Mar 2024 16:01:50 -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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V6Xpg6mJzz520P On Sat, Mar 30, 2024 at 2:45=E2=80=AFPM Andreas Kempe wrote: > > On Thu, Mar 28, 2024 at 06:13:00AM -0700, Rick Macklem wrote: > > 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 attrib= utes 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 > > > > > > > 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 comm= and line option > > > > > > > > on nfsuserd to set it. > > > > > > > > (Since this "domain" is underdefined, I'd suggest only asci= i 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 serve= r. It > > > > > > seems to work since listing files give correct owners. > > > > > > > > > > > > I have dumped the traffic from mounting and creating a file nam= ed > > > > > > 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: 0x= 30a4c0aa/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 expe= cted > > > > > > 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 sho= uld 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= wireshark. > > > > > 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 t= o > > > see what their > > > values are). It does know kempe@lysator.liu.se, since that is reporte= d > > > 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 attrib= utes), > > 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 togg= led > > 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? The only setable attribute specified by the Open request is "mode". That just means that the server is expected to create the file with an ownership of the Kerberos principal used in the RPC credentials. Now, if you are doing the RPC as root, that will result in nobody (or a failure to create the file, depending upon directory permissions). There is no way to know what user principal is represented by the RPCSEC_GSS credentials, since they are a shorthand for the Kerberos credentials presented in a Null RPC that happens when there is no credential. When creating a file, the user creating the file will need to have a valid TGT in the client's credential cache. And the user principal name (without @REALM) must be a name in the passwd database. rick > > > > rick > > > > > > > > > rick > > > > > ps: If that is what is in the Owner field, all I can suggest is t= hat was what > > > > > a getpwnam() returned on the client. Possibly some weirdnes= s 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 fiel= d are > > > > > > supposed to be. They are not the ASCII representation and nithe= r my > > > > > > user's GID and UID that are both 0x7b02. > > > > > > > > > > > > // Andreas Kempe > > > > > > > > > > > >