public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Steve Dickson <steved@redhat.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	JianHong Yin <jiyin@redhat.com>
Subject: Re: [nfs-utils PATCH] Don't allow junction tests to trigger automounts
Date: Tue, 13 Dec 2022 11:41:18 -0500	[thread overview]
Message-ID: <bf761c780a2c65907718a107e84bf1e5cfe6756f.camel@kernel.org> (raw)
In-Reply-To: <52DA8A58-FF23-4528-B094-D8849D1DE54A@oracle.com>

On Tue, 2022-12-13 at 16:25 +0000, Chuck Lever III wrote:
> 
> > On Dec 13, 2022, at 11:01 AM, Jeff Layton <jlayton@kernel.org> wrote:
> > 
> > JianHong reported some strange behavior with automounts on an nfs server
> > without an explicit pseudoroot. When clients issued a readdir in the
> > pseudoroot, automounted directories that were not yet mounted would show
> > up even if they weren't exported, though the clients wouldn't be able to
> > do anything with them.
> > 
> > The issue was that triggering the automount on a directory would cause
> > the mountd upcall to time out, which would cause nfsd to include the
> > automounted dentry in the readdir response. Eventually, the automount
> > would work and report that it wasn't exported and subsequent attempts to
> > access the dentry would (properly) fail.
> > 
> > We never want mountd to trigger an automount. The kernel should do that
> > if it wants to use it. Change the junction checks to do an O_PATH open
> > and use fstatat with AT_NO_AUTOMOUNT.
> > 
> > Cc: Chuck Lever <chuck.lever@oracle.com>
> > Link: https://bugzilla.redhat.com/show_bug.cgi?id=2148353
> 
> And also https://bugzilla.kernel.org/show_bug.cgi?id=216777 ?
> 

Yes indeed, thanks! Note too that I suspect there may also be a kernel
error handling bug related to this.

I know that nfsd_cross_mnt returned -ETIMEDOUT, but the READDIR response
still contained the dentry. The follow-on stat call failed, but it seems
like the readdir response shouldn't have included that dentry in the
first place.

I'm still looking at that bit, but we should probably aim to fix that
too.

> 
> > Reported-by: JianHong Yin <jiyin@redhat.com>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > support/junction/junction.c | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/support/junction/junction.c b/support/junction/junction.c
> > index 41cce261cb52..0628bb0ffffb 100644
> > --- a/support/junction/junction.c
> > +++ b/support/junction/junction.c
> > @@ -63,7 +63,7 @@ junction_open_path(const char *pathname, int *fd)
> > 	if (pathname == NULL || fd == NULL)
> > 		return FEDFS_ERR_INVAL;
> > 
> > -	tmp = open(pathname, O_DIRECTORY);
> > +	tmp = open(pathname, O_PATH|O_DIRECTORY);
> > 	if (tmp == -1) {
> > 		switch (errno) {
> > 		case EPERM:
> > @@ -93,7 +93,7 @@ junction_is_directory(int fd, const char *path)
> > {
> > 	struct stat stb;
> > 
> > -	if (fstat(fd, &stb) == -1) {
> > +	if (fstatat(fd, "", &stb, AT_NO_AUTOMOUNT|AT_EMPTY_PATH) == -1) {
> > 		xlog(D_GENERAL, "%s: failed to stat %s: %m",
> > 				__func__, path);
> > 		return FEDFS_ERR_ACCESS;
> > @@ -121,7 +121,7 @@ junction_is_sticky_bit_set(int fd, const char *path)
> > {
> > 	struct stat stb;
> > 
> > -	if (fstat(fd, &stb) == -1) {
> > +	if (fstatat(fd, "", &stb, AT_NO_AUTOMOUNT|AT_EMPTY_PATH) == -1) {
> > 		xlog(D_GENERAL, "%s: failed to stat %s: %m",
> > 				__func__, path);
> > 		return FEDFS_ERR_ACCESS;
> > @@ -155,7 +155,7 @@ junction_set_sticky_bit(int fd, const char *path)
> > {
> > 	struct stat stb;
> > 
> > -	if (fstat(fd, &stb) == -1) {
> > +	if (fstatat(fd, "", &stb, AT_NO_AUTOMOUNT|AT_EMPTY_PATH) == -1) {
> > 		xlog(D_GENERAL, "%s: failed to stat %s: %m",
> > 			__func__, path);
> > 		return FEDFS_ERR_ACCESS;
> > @@ -393,7 +393,7 @@ junction_get_mode(const char *pathname, mode_t *mode)
> > 	if (retval != FEDFS_OK)
> > 		return retval;
> > 
> > -	if (fstat(fd, &stb) == -1) {
> > +	if (fstatat(fd, "", &stb, AT_NO_AUTOMOUNT|AT_EMPTY_PATH) == -1) {
> > 		xlog(D_GENERAL, "%s: failed to stat %s: %m",
> > 			__func__, pathname);
> > 		(void)close(fd);
> > -- 
> > 2.38.1
> > 
> 
> --
> Chuck Lever
> 
> 
> 

-- 
Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2022-12-13 16:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-13 16:01 [nfs-utils PATCH] Don't allow junction tests to trigger automounts Jeff Layton
2022-12-13 16:25 ` Chuck Lever III
2022-12-13 16:41   ` Jeff Layton [this message]
2023-01-04 12:23 ` Jeff Layton
2023-01-11 15:55 ` Steve Dickson

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=bf761c780a2c65907718a107e84bf1e5cfe6756f.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=jiyin@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.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