From nobody Sun Apr 14 15:26:06 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 4VHYzm109Tz5GmsT for ; Sun, 14 Apr 2024 15:26:12 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VHYzk57CYz4Jq2 for ; Sun, 14 Apr 2024 15:26:10 +0000 (UTC) (envelope-from kempe@lysator.liu.se) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=lysator.liu.se; spf=pass (mx1.freebsd.org: domain of kempe@lysator.liu.se designates 130.236.254.3 as permitted sender) smtp.mailfrom=kempe@lysator.liu.se Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 2C6901D975; Sun, 14 Apr 2024 17:26:07 +0200 (CEST) Received: from shipon.lysator.liu.se (shipon.lysator.liu.se [IPv6:2001:6b0:17:f0a0::83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 13EC51DAA5; Sun, 14 Apr 2024 17:26:07 +0200 (CEST) Date: Sun, 14 Apr 2024 17:26:06 +0200 From: Andreas Kempe To: Rick Macklem Cc: freebsd-fs@freebsd.org Subject: Re: Kerberised NFSv4 - everyone gets mapped to nobody on file access Message-ID: References: List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.98)[-0.975]; DMARC_POLICY_ALLOW(-0.50)[lysator.liu.se,none]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; RCVD_IN_DNSWL_MED(-0.20)[130.236.254.3:from]; MIME_GOOD(-0.10)[text/plain]; TO_DN_SOME(0.00)[]; MISSING_XM_UA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:2843, ipnet:130.236.0.0/16, country:SE]; TAGGED_RCPT(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; ARC_NA(0.00)[] X-Rspamd-Queue-Id: 4VHYzk57CYz4Jq2 On Sat, Mar 30, 2024 at 04:01:50PM -0700, Rick Macklem wrote: > On Sat, Mar 30, 2024 at 2:45 PM Andreas Kempe wrote: > > 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. > After having let this brew in the back of my mind for a while, I realised what the issue was thanks to you explaining the use of the principal to figure out the user. For our usecase, I wanted to only authenticate the machine because users have cronjobs running in their home directories, users want to access each other's files and log in using SSH keys. I was mounting using -o nfsv4,sec=krb5p,allgssname,gssname=host thinking that allgssname would allow users to use the machine's principal and that ownership information would be sent along with the requests. From what you wrote, Rick, I gather that this causes all users to be mapped to nobody because the machine's principal is used. Removing allgssname and doing a kinit has things working as expected when I mount using -o nfsv4,sec=krb5p,gssname=host and makes me own files I create. Am I correct in thinking that Kerberos isn't really designed to be used for only authenticating the machine? Users having to always have their own valid Kerberos ticket doesn't really work for us. Best regards, Andreas Kempe