From: "Pali Rohár" <pali@kernel.org>
To: Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 3/5] nfs: Try to use AUTH_NULL for NFS3 mount when no -o sec was given
Date: Thu, 12 Sep 2024 15:02:18 +0200 [thread overview]
Message-ID: <20240912130220.17032-4-pali@kernel.org> (raw)
In-Reply-To: <20240912130220.17032-1-pali@kernel.org>
As an absolutely last chance, after all previous failed attempts, try to
use also AUTH_NULL when mounting NFS3 export. Try AUTH_NULL also when MNTv3
server does not announce it because of Linux MNTv3 server rpc.mountd bug
which does not announce AUTH_NULL even when this is the only allowed method
on the server.
Currently AUTH_NULL is always skipped in nfs_try_mount_request() function
even when MNTv3 server announces it and so it is not possible to mount NFS3
export with AUTH_UNIX disallowed on server.
nfs_try_mount_request() function currently tries AUTH_UNIX method even when
server does not announces it. But it does not try to use AUTH_NULL when
server announces AUTH_NULL.
With this patch, AUTH_UNIX behavior as described above is not changed and
after the AUTH_UNIX attempt is added AUTH_NULL attempt as the absolutely
last chance.
With this patch it is possible to mount NFS3 exports with AUTH_NULL method
if all other methods are rejected by server. AUTH_NULL method is useful for
public read-only data exports which do not require any user authentication.
This change fixes mounting of NFS3 AUTH_NULL-only exports without need to
specify any special mount options, like -o sec.
Signed-off-by: Pali Rohár <pali@kernel.org>
Cc: stable@vger.kernel.org
---
fs/nfs/super.c | 46 +++++++++++++++++++++++++++++++++++++---------
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 3fef2afd94bd..4cb319be55ca 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -911,6 +911,7 @@ static struct nfs_server *nfs_try_mount_request(struct fs_context *fc)
struct nfs_fs_context *ctx = nfs_fc2context(fc);
int status;
unsigned int i;
+ int first_err = 0;
bool tried_auth_unix = false;
bool auth_null_in_list = false;
struct nfs_server *server = ERR_PTR(-EACCES);
@@ -947,7 +948,8 @@ static struct nfs_server *nfs_try_mount_request(struct fs_context *fc)
/*
* No sec= option was provided. RFC 2623, section 2.7 suggests we
* SHOULD prefer the flavor listed first. However, some servers list
- * AUTH_NULL first. Avoid ever choosing AUTH_NULL.
+ * AUTH_NULL first. So skip AUTH_NULL here and try it as an absolutely
+ * last chance at the end of this function.
*/
for (i = 0; i < authlist_len; ++i) {
rpc_authflavor_t flavor;
@@ -971,20 +973,46 @@ static struct nfs_server *nfs_try_mount_request(struct fs_context *fc)
server = ctx->nfs_mod->rpc_ops->create_server(fc);
if (!IS_ERR(server))
return server;
+ if (!first_err)
+ first_err = PTR_ERR(server);
}
/*
- * Nothing we tried so far worked. At this point, give up if we've
- * already tried AUTH_UNIX or if the server's list doesn't contain
- * AUTH_NULL
+ * If AUTH_UNIX was not available in the server's list and AUTH_NULL was
+ * then for compatibility with old NFS3 servers try also AUTH_UNIX.
*/
- if (tried_auth_unix || !auth_null_in_list)
+ if (!tried_auth_unix && auth_null_in_list) {
+ dfprintk(MOUNT,
+ "NFS: attempting to use auth flavor %u%s\n",
+ RPC_AUTH_UNIX,
+ ", even it was not announced by server");
+ ctx->selected_flavor = RPC_AUTH_UNIX;
+ server = ctx->nfs_mod->rpc_ops->create_server(fc);
+ if (!IS_ERR(server))
+ return server;
+ tried_auth_unix = true;
+ }
+
+ /*
+ * Linux MNTv3 server rpc.mountd since nfs-utils version 1.1.3, commit
+ * https://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=3c1bb23c0379
+ * does not include AUTH_NULL into server's list export response even
+ * when AUTH_NULL is supported and enabled for that export on Linux
+ * NFS3 server. AUTH_NULL was skipped when processing server's list,
+ * so always try AUTH_NULL as an absolutely last chance and also when
+ * it was not available in the server's list.
+ */
+ dfprintk(MOUNT,
+ "NFS: attempting to use auth flavor %u%s\n",
+ RPC_AUTH_NULL,
+ auth_null_in_list ? "" : ", even it was not announced by server");
+ ctx->selected_flavor = RPC_AUTH_NULL;
+ server = ctx->nfs_mod->rpc_ops->create_server(fc);
+ if (!IS_ERR(server))
return server;
- /* Last chance! Try AUTH_UNIX */
- dfprintk(MOUNT, "NFS: attempting to use auth flavor %u\n", RPC_AUTH_UNIX);
- ctx->selected_flavor = RPC_AUTH_UNIX;
- return ctx->nfs_mod->rpc_ops->create_server(fc);
+ /* Prefer error code from the first attempt of server's list. */
+ return first_err ? ERR_PTR(first_err) : server;
}
int nfs_try_get_tree(struct fs_context *fc)
--
2.20.1
next prev parent reply other threads:[~2024-09-12 13:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-12 13:02 [PATCH 0/5] nfs: Fix mounting NFS3 AUTH_NULL exports Pali Rohár
2024-09-12 13:02 ` [PATCH 1/5] nfs: Fix support for NFS3 mount with -o sec=none from Linux MNTv3 server Pali Rohár
2024-09-12 13:02 ` [PATCH 2/5] nfs: Propagate AUTH_NULL/AUTH_UNIX PATHCONF NFS3ERR_ACCESS failures Pali Rohár
2024-09-12 13:02 ` Pali Rohár [this message]
2024-09-12 13:02 ` [PATCH 4/5] nfs: Fix -o sec=none output in /proc/mounts Pali Rohár
2024-09-12 13:02 ` [PATCH 5/5] nfs: Remove duplicate debug message 'using auth flavor' Pali Rohár
2024-09-12 21:06 ` [PATCH 0/5] nfs: Fix mounting NFS3 AUTH_NULL exports Anna Schumaker
2024-09-12 21:11 ` Pali Rohár
2024-10-05 15:15 ` Pali Rohár
2024-10-28 9:54 ` Pali Rohár
2024-12-22 16:40 ` Pali Rohár
2025-04-18 18:03 ` Pali Rohár
2025-05-04 8:48 ` Pali Rohár
2025-05-18 9:57 ` Pali Rohár
2025-09-20 13:35 ` Pali Rohár
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=20240912130220.17032-4-pali@kernel.org \
--to=pali@kernel.org \
--cc=anna@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=trondmy@kernel.org \
/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