All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Christoph Hellwig <hch@infradead.org>,
	Frank van Maarseveen <frankvm@frankvm.com>,
	Neil Brown <neilb@suse.de>, Christoph Hellwig <hch@lst.de>,
	Linux NFS mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] exportfs: fix incorrect EACCES in reconnect_path()
Date: Fri, 2 May 2008 18:12:16 -0400	[thread overview]
Message-ID: <20080502221216.GP21918@fieldses.org> (raw)
In-Reply-To: <1209744293.8294.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>

On Fri, May 02, 2008 at 12:04:53PM -0400, Trond Myklebust wrote:
> 
> On Fri, 2008-05-02 at 11:56 -0400, J. Bruce Fields wrote:
> > On Fri, May 02, 2008 at 11:34:39AM -0400, Christoph Hellwig wrote:
> > > On Fri, May 02, 2008 at 05:16:46PM +0200, Frank van Maarseveen wrote:
> > > > A privileged process on an NFS client which drops privileges after using
> > > > them to change the current working directory, will experience incorrect
> > > > EACCES after an NFS server reboot. This problem can also occur after
> > > > memory pressure on the server, particularly when the client side is
> > > > quiet for some time.
> > > > 
> > > > This patch removes the x-bit check during dentry tree reconstruction at
> > > > the server by exportfs on behalf of nfsd.
> > > 
> > > I'm still against adding this crap,
> > 
> > The only statements I've seen against the change so far have been of the
> > form "you should not do that", without explaining why not.
> > 
> > It's entirely possible that you're right, but I need some argument.
> 
> 
> AFAICS, the real problem here is that nfsd is dropping its privileged
> mode too early. Why can't you call reconnect_path() using nfsd's root
> permissions instead of dropping permissions checks altogether?

That's an interesting idea.

As I understand it, nfsd sets the current task's credentials only once,
in nfsd_setuser, called from fh_verify().  The change lingers around
until next time we do fh_verify().  So in addition to moving the
nfsd_setuser() call to after the lookup of the dentry (so after
exportfs_decode_fh(), we'd also need to add an explicit acquisition of
whatever permissions we need before we do that lookup.

--b.

> 
> > > and even when I get overruled that
> > > doesn't make the comments on lookup_one_noperm any less true,
> > 
> > We do need to at least update it to reflect the addition of a new
> > caller.
> > 
> > > not does it give you a permit to break the kerneldoc generation.
> > 
> > Oops; here's a version that should make kerneldoc happy.  It also adds a
> > little more explanation, and leaves alone the editorializing on sysfs
> > (on which I have no opinion).
> > 
> > --b.
> > 
> > commit ccdfe77dc49a07c298bb9e2107290267492f16b3
> > Author: Frank van Maarseveen <frankvm@frankvm.com>
> > Date:   Fri May 2 17:16:46 2008 +0200
> > 
> >     exportfs: fix incorrect EACCES in reconnect_path()
> >     
> >     A privileged process on an NFS client which drops privileges after using
> >     them to change the current working directory, will experience incorrect
> >     EACCES after an NFS server reboot. This problem can also occur after
> >     memory pressure on the server, particularly when the client side is
> >     quiet for some time.
> >     
> >     This patch removes the x-bit check during dentry tree reconstruction at
> >     the server by exportfs on behalf of nfsd.
> >     
> >     Signed-off-by: Frank van Maarseveen <frankvm@frankvm.com>
> >     Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
> > 
> > diff --git a/fs/exportfs/expfs.c b/fs/exportfs/expfs.c
> > index 109ab5e..89dc7ae 100644
> > --- a/fs/exportfs/expfs.c
> > +++ b/fs/exportfs/expfs.c
> > @@ -170,7 +170,7 @@ reconnect_path(struct vfsmount *mnt, struct dentry *target_dir)
> >  			}
> >  			dprintk("%s: found name: %s\n", __FUNCTION__, nbuf);
> >  			mutex_lock(&ppd->d_inode->i_mutex);
> > -			npd = lookup_one_len(nbuf, ppd, strlen(nbuf));
> > +			npd = lookup_one_noperm(nbuf, ppd);
> >  			mutex_unlock(&ppd->d_inode->i_mutex);
> >  			if (IS_ERR(npd)) {
> >  				err = PTR_ERR(npd);
> > @@ -447,8 +447,7 @@ struct dentry *exportfs_decode_fh(struct vfsmount *mnt, struct fid *fid,
> >  		err = exportfs_get_name(mnt, target_dir, nbuf, result);
> >  		if (!err) {
> >  			mutex_lock(&target_dir->d_inode->i_mutex);
> > -			nresult = lookup_one_len(nbuf, target_dir,
> > -						 strlen(nbuf));
> > +			nresult = lookup_one_noperm(nbuf, target_dir);
> >  			mutex_unlock(&target_dir->d_inode->i_mutex);
> >  			if (!IS_ERR(nresult)) {
> >  				if (nresult->d_inode) {
> > diff --git a/fs/namei.c b/fs/namei.c
> > index e179f71..c00150c 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -1391,7 +1391,7 @@ struct dentry *lookup_one_len(const char *name, struct dentry *base, int len)
> >  }
> >  
> >  /**
> > - * lookup_one_noperm - bad hack for sysfs
> > + * lookup_one_noperm - bad hack for sysfs and nfsd
> >   * @name:	pathname component to lookup
> >   * @base:	base directory to lookup from
> >   *
> > @@ -1399,7 +1399,12 @@ struct dentry *lookup_one_len(const char *name, struct dentry *base, int len)
> >   * checks.   It's a horrible hack to work around the braindead sysfs
> >   * architecture and should not be used anywhere else.
> >   *
> > - * DON'T USE THIS FUNCTION EVER, thanks.
> > + * It is also used by nfsd via exports to reconstruct the dentry tree
> > + * for directory handles (e.g. when a client requests a directory by
> > + * filehandle after a server reboot has cleared the dentry cache of that
> > + * directory's parents).
> > + *
> > + * DON'T USE THIS FUNCTION ANYWHERE ELSE, thanks.
> >   */
> >  struct dentry *lookup_one_noperm(const char *name, struct dentry *base)
> >  {
> 
> How about if exportfs is compiled as a module?
> 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  parent reply	other threads:[~2008-05-02 22:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-04 10:24 reconnect_path() breaks NFS server causing occasional EACCES Frank van Maarseveen
2008-04-07 18:43 ` J. Bruce Fields
2008-04-07 19:55   ` Frank van Maarseveen
2008-04-09 13:36   ` Christoph Hellwig
2008-04-09 14:11     ` Frank van Maarseveen
2008-04-09 16:24     ` J. Bruce Fields
2008-04-29  5:20     ` Neil Brown
     [not found]       ` <18454.45086.254692.412079-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-04-29 16:35         ` J. Bruce Fields
2008-04-29 17:40           ` Frank van Maarseveen
2008-04-30 17:47             ` J. Bruce Fields
2008-05-02 15:16               ` [PATCH] exportfs: fix incorrect EACCES in reconnect_path() Frank van Maarseveen
2008-05-02 15:34                 ` Christoph Hellwig
2008-05-02 15:56                   ` J. Bruce Fields
2008-05-02 16:04                     ` Trond Myklebust
     [not found]                       ` <1209744293.8294.19.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-05-02 22:12                         ` J. Bruce Fields [this message]
2008-05-04 23:22                           ` Neil Brown
     [not found]                             ` <18462.17737.353976.999538-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-05-05 17:47                               ` J. Bruce Fields
2008-05-06  0:35                                 ` Neil Brown
     [not found]                                   ` <18463.42978.531115.344884-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-05-06 19:50                                     ` J. Bruce Fields
2008-05-08  3:03                                       ` Neil Brown
     [not found]                                         ` <18466.28013.258338.485948-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2008-05-09  4:34                                           ` J. Bruce Fields
2008-05-09 10:11                                             ` Frank van Maarseveen
2008-06-29 19:27                                               ` J. Bruce Fields
2008-05-03  8:52                         ` Frank van Maarseveen
2008-04-30 23:29           ` reconnect_path() breaks NFS server causing occasional EACCES Neil Brown

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=20080502221216.GP21918@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=frankvm@frankvm.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=trond.myklebust@fys.uio.no \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.