From: Trond Myklebust <trondmy@kernel.org>
To: Rick Macklem <rick.macklem@gmail.com>, linux-nfs@vger.kernel.org
Subject: Re: RFC:Doing a NFSv4.1/4.2 Kerberized mount without a machine credential
Date: Tue, 03 Jan 2023 21:12:16 -0500 [thread overview]
Message-ID: <e9fea39e926486146505c385dca50c116deb22f9.camel@kernel.org> (raw)
In-Reply-To: <CAM5tNy6nfvuqM30DwUVjTFHfewL8tSEQcyEJsSBzyWMTvDkEQw@mail.gmail.com>
On Tue, 2023-01-03 at 17:28 -0800, Rick Macklem wrote:
> I have recently implemented a NFSv4.1/4.2 client mount
> on FreeBSD that uses AUTH_SYS for ExchangeID, CreateSession
> (and the other state maintenance operations)
> using SP4_NONE and then it defers an RPC that does:
> PutRootFH { Lookup, Lookup,... Lookup } GetFH
> until a user process/thread attempts to use the mount.
> Once an attempt succeeds, the file handle for the mount
> point is filled in and the mount works normally.
> This works for both a FreeBSD NFSv4 server and a Linux
> 5.15 one.
>
> Why do this?
>
> It allows a sec=krb5 mount to work without any
> machine credential on the client. (Both installing
> a keytab entry for a host/nfs-client.domain in the
> client or doing the mount based on a user principal's
> TGT are bothersome.) The first user with a valid TGT
> that attempts to access the mount completes the mount's
> setup.
>
> I envision that this will be used along with RPC-with-TLS
> (which can provide both on-the-wire encryption and
> peer authentication). The seems to be a reasonable
> alternative to a machine credential and a requirement
> for RPCSEC_GSS integrity or privacy.
>
> Why am I posting here?
>
> I am wondering if the Linux client implementors are
> interested in doing the same thing?
>
> I think it is possible to extend NFSv4.2 with a new
> enum state_protect_how4 value (SP4_PEER_AUTH?) that
> would allow the client to specify what operations must
> use RPC-with-TLS including peer authentication and which
> must be allowed for this case (similar to SP4_MECH_CRED).
> However, if the server forces the client to use RPC-with-TLS
> plus peer authentication, that may be sufficient and does
> not require any protocol extensions.
>
> Comments?
>
Are there really that many use cases for this? If you are using krb5
authentication, then you pretty much have to support identity mapping.
Unless you are talking about a hobby setup, then that usually means
backing your Kerberos server with either LDAP or Active Directory to
serve up account mappings, and it usually means protecting those
databases with some form of strong authentication as well.
IOW: for most setups, I would expect the machine credential requirement
to be a non-negotiable part of the total AD/Krb5+LDAP security package
that is implemented in userspace. Am I wrong?
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2023-01-04 2:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-04 1:28 RFC:Doing a NFSv4.1/4.2 Kerberized mount without a machine credential Rick Macklem
2023-01-04 2:12 ` Trond Myklebust [this message]
2023-01-04 3:16 ` Rick Macklem
2023-01-04 4:41 ` Trond Myklebust
2023-01-04 14:25 ` Chuck Lever III
2023-01-04 15:32 ` Rick Macklem
2023-01-04 17:25 ` Trond Myklebust
2023-01-04 18:06 ` Chuck Lever III
2023-01-04 18:34 ` Trond Myklebust
2023-01-04 18:34 ` Olga Kornievskaia
2023-01-04 18:51 ` Trond Myklebust
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e9fea39e926486146505c385dca50c116deb22f9.camel@kernel.org \
--to=trondmy@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=rick.macklem@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox