All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Clay McClure <clay-zo/yENU/GurR7s880joybQ@public.gmane.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)
Date: Mon, 05 May 2008 16:29:37 -0400	[thread overview]
Message-ID: <1210019377.7448.12.camel@localhost> (raw)
In-Reply-To: <loom.20080505T174704-239-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>

On Mon, 2008-05-05 at 18:27 +0000, Clay McClure wrote:
> Trond Myklebust <trond.myklebust <at> fys.uio.no> writes:
> 
> > On Fri, 2007-07-06 at 09:40 -0400, Peter Staubach wrote:
> > > It was misguided on someone's part to think that no ACLs meant that
> > > checking the mode bits for permissions was sufficient.
> > 
> > Yup.
> 
> It seems to me that disabling ACCESS might prevent clients from knowing
> whether an operation is allowed, but it would not allow clients to bypass
> server ACLs. From a security perspective, then, I would think disabling
> ACCESS would not affect the correctness of the protocol.
> 
> In other words, if a client with ACCESS disabled determined (by mode
> bits alone) that a read operation was allowed, and issued a READ call,
> would the server still determine whether the request was allowed
> (according to its ACL and user mapping policy), and return
> NFS3ERR_ACCES if not?

Yes, but that was never the problem. The problem is that clients can and
do cache data, and need to know who is allowed to access that data.

> > The correct way to deal with the problem of too many ACCESS calls
> > was rather to improve the caching. There should be a vast difference
> > between a 2.6.19 kernel or higher and earlier versions when it comes to
> > the ability to cache credentials from multiple users and I hope that
> > addresses the problems that people were seeing.
> 
> ACCESS calls make up 17% of the NFS ops generated by our application
> running on a stock CentOS 5 2.6.18 kernel. We don't use ACLs or root
> mapping. One user (root) performs all file access on the NFS volume
> in question.
> 
> Would the credential caching you mention in 2.6.19 help us reduce the
> number of ACCESS operations we see (even though only one user is
> performing file I/O)?

Since CentOS 5 is a copy of RHEL-5, I would expect it to already have
the patch applied.

> Is it safe to apply a patch to eliminate ACCESS altogether?

In general? No (see above).

That said, you can always find corner cases with peculiar environments.
Perhaps in your particular environment where there is only one user,
removing access is safe and will actually produce a win, as opposed to
generating yet more GETATTR calls in order to revalidate the cached
modebit data. It all depends on the underlying reason for why you are
seeing such a high number of ACCESS calls.

   Trond


      parent reply	other threads:[~2008-05-05 20:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-05 21:01 'noacl' NFS parameter seems ineffective (Fedora Core 7) Myles Uyema
2007-07-05 21:19 ` Peter Staubach
2007-07-05 21:39   ` Myles Uyema
2007-07-06 11:46     ` Peter Staubach
2007-07-06 13:24   ` Trond Myklebust
2007-07-06 13:40     ` Peter Staubach
2007-07-06 14:27       ` Trond Myklebust
2008-05-05 18:27         ` Clay McClure
     [not found]           ` <loom.20080505T174704-239-eS7Uydv5nfjZ+VzJOa5vwg@public.gmane.org>
2008-05-05 20:29             ` Trond Myklebust [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=1210019377.7448.12.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=clay-zo/yENU/GurR7s880joybQ@public.gmane.org \
    --cc=linux-nfs@vger.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 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.