From nobody Mon Apr 15 22:14:18 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 4VJM0S2SHYz5HCN2 for ; Mon, 15 Apr 2024 22:14:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 4VJM0R6L6Jz4mvJ for ; Mon, 15 Apr 2024 22:14:31 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-2a536b08d63so2210085a91.1 for ; Mon, 15 Apr 2024 15:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713219270; x=1713824070; 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=DytulzHrnHjAfras6302/pgQpGGICjeScDG+yvV+Z/A=; b=WnVLBZJyVNfruNf5mGryEHnLgd5u94VZJ7a3uUk7826OwcEChSMVuSpmpTbv4k3JnK NGBXXBBln3gBbUcD9U8q97wBm/3uDl4LTrnPw1f+hSe/YzaKl2rq7UabcYHHg/8lZBEm ET9zM1IBf4vrAZl6DAa11g5TZwJwz9TWOsoihhweOSdT5u17gf9WDC+k+NiKkN3iI+Nt 2wats5LoVJyTkY/HlI0qJ/4ebWT+oO3nBYWqngn30NWxVJTWImDkoKLZGpuNUXMXKO1+ 3PGCqTfzcpPxn9olpa2LmTh4rvXthu3Q8Pr9oQ6NECs5g8/kCE3MksXFdBh0qS94elR+ wU7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713219270; x=1713824070; 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=DytulzHrnHjAfras6302/pgQpGGICjeScDG+yvV+Z/A=; b=AbkMRnPh1WcSS9FtbrZDBaoSRN9djawqjUVTXX3ojc0+mFq1VzCBv5TacLSV8xXkmr TE9CdKZVJA94WL3SPHr9vNXMjVL+b1sYKgSIA1Cn3JXJxi0LQHnYIYB5U9fbVHMci8Y8 MDl4O1vMzwwXKHz5UqqmAGt5jXMrMG/7vbJp7oFAjyWxxZ5XKIV3N8DxrVPdHabouj1u Orw0u7/UxFPqivBayH8UEcv0+HzPqfxbWYc3QojnAPI8BU9goGTjD6coztCEtc4yf10L +sbpsiW4CwkiNUaeZVwqwOtt9j3K34Iz+E4VEKjSSKffuSnPg72WV0V8aMdXIvoHy4PT hQCg== X-Gm-Message-State: AOJu0YzNRj6IadYXLCUw1u/fCrs3ADPXBFBn8nydUYBgHLn4mSiqVH6a PN/R8ZvdOrDS8TbVzTvo3N7Xv7Nf4xVfwP7lmOKZjxwis6OQTiFumnwbpX2bIl+DYuKx3JmYl4F aQd9I7U/xr3wgpP6SarGPr8s+ig== X-Google-Smtp-Source: AGHT+IGweZKZ+3azJ0cOnI/ZUrJzdiFhnF3tqeR68tqYeJlY19EZaMio0bc8/XiT6M132cw6sd30o541Bf+FKmxvnPA= X-Received: by 2002:a17:90a:bb15:b0:2a2:88c0:19d8 with SMTP id u21-20020a17090abb1500b002a288c019d8mr8896291pjr.39.1713219269903; Mon, 15 Apr 2024 15:14:29 -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: Mon, 15 Apr 2024 15:14:18 -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: 4VJM0R6L6Jz4mvJ On Mon, Apr 15, 2024 at 12:53=E2=80=AFPM Andreas Kempe wrote: > > On Sun, Apr 14, 2024 at 12:30:22PM -0700, Rick Macklem wrote: > > On Sun, Apr 14, 2024 at 8:26=E2=80=AFAM Andreas Kempe wrote: > > > 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. > > Yes. The "host" keytab credential is a "hack". Kerberos calls them > > service principals and they were not intended to authenticate a machine > > when Kerberos was designed. > > > > If users are running cron jobs, then one way around the problem > > is to have the KDC issue renewable tickets and then run a daemon > > (can't remember the name, but it is easy to find and opensourced) > > that renews TGTs. (This only works up to the renew limit of the KDC > > config.) > > > > I have seen that this should be possible, the Linux SSSD daemon can do > that. We do still have the issue of users having to log on to every > system after a reboot to init a ticket so I still don't think it would > be ideal for us. > > > NFS-over-TLS (called RPC-over-TLS by the Linux folk) does allow > > a client to provide a X.509 certificate during TLS handshake to > > identify the client machine and the TLS encrypts everything on > > the wire to avoid middleman attacks or snoopers. > > It does not identify users on the server, unless TLS identity > > squashing is used via the X.509 certificate to make all RPCs > > done by a user. (This has the advantage that it is not "nobody", > > but is only useful for things like laptops, that are only used by > > one user. It does have the advantage that there are no tickets > > to expire, although there is a, usually long, expiration on the X.509 > > certificate.) > > > > If I'm running NFS with TLS without TLS identity squashing, does this > mean that users are resolved the same way they are with sec=3Dsys? It depends on what mount options are used. For FreeBSD clients, sec=3Dsys is the default, so that is what will be used unless "sec=3Dkrb5" is specifi= ed. I am not sure how the Linux client decides this. (It may be sec=3Dsys as well, but I am not sure?) > If > so, this could be the solution we are looking for if I can make sure > that all our Linux systems that need to mount have a new enough Linux > kernel to support it. Yep. I know the kernel patches now exist, but I do not know what kernel version you need to get them. rick > > // Andreas Kempe