All of lore.kernel.org
 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 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.