linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Rajesh Ghanekar <rajeshsg@gmail.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: reconnect_path fails with EACCES
Date: Mon, 13 Aug 2012 10:30:16 -0400	[thread overview]
Message-ID: <20120813143016.GA2497@fieldses.org> (raw)
In-Reply-To: <CAOn_VZaNU1_WT+XsvHabi=4fhMnyJg5eKp_p=e=1ruWfHC76DQ@mail.gmail.com>

On Mon, Aug 13, 2012 at 07:24:56PM +0530, Rajesh Ghanekar wrote:
> Its no_subtree_check exported.
> 
> Underneath filesystem (->permission) doesn't support capabilities and
> hence EACCES is being returned. The filesystem is proprietary.
> I figured it out later that they don't support capabilities.

That sounds like a bug in their permission method.  We won't be able to
help with a proprietary filesystem here.

--b.

> 
> Thanks,
> Rajesh
> 
> 
> On Thu, Aug 9, 2012 at 11:42 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Thu, Aug 09, 2012 at 02:55:28AM +0530, Rajesh Ghanekar wrote:
> >> Hi,
> >> I am facing problem with reconnect_path failing with EACCES when doing
> >> lookup_one_len. I have 2 users goind to same directory, one with uid=0
> >> and another with uid=xxx. Sometime for uid=0 request, nfsd is still is using
> >> uid=xxx (as it was used previously), as uid=xxx doesn't have any permissions
> >> on the directory.
> >>
> >> Should this probably do nfsd_setuser_and_check_port before
> >> the below code in nfsd_set_fh_dentry()? As it carries older
> >> fsuid and fsgid, can it create issues. This always happens
> >> with disconnected dentries.
> >>
> >>         if (exp->ex_flags & NFSEXP_NOSUBTREECHECK) {
> >>                 /* Elevate privileges so that the lack of 'r' or 'x'
> >>                  * permission on some parent directory will
> >>                  * not stop exportfs_decode_fh from being able
> >>                  * to reconnect a directory into the dentry cache.
> >>                  * The same problem can affect "SUBTREECHECK" exports,
> >>                  * but as nfsd_acceptable depends on correct
> >>                  * access control settings being in effect, we cannot
> >>                  * fix that case easily.
> >
> > Are you exporting with subtree_check or no_subtree_check?  (What does
> > "exportfs -v" say?)
> >
> > In the no_subtree_check case, the cap_raise_nfsd_set() is intended to
> > override file permissions, so the uid and gid shouldn't matter.
> >
> > --b.

      reply	other threads:[~2012-08-13 14:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-08 21:25 reconnect_path fails with EACCES Rajesh Ghanekar
2012-08-09 18:12 ` J. Bruce Fields
2012-08-13 13:54   ` Rajesh Ghanekar
2012-08-13 14:30     ` J. Bruce Fields [this message]

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=20120813143016.GA2497@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=rajeshsg@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;
as well as URLs for NNTP newsgroup(s).