From: "J. Bruce Fields" <bfields@fieldses.org>
To: Andrew W Elble <aweits@rit.edu>
Cc: linux-nfs@vger.kernel.org, dros@primarydata.com
Subject: Re: [PATCH v2 3/3] nfsd: implement machine credential support for some operations
Date: Fri, 22 Jan 2016 11:36:20 -0500 [thread overview]
Message-ID: <20160122163620.GD9082@fieldses.org> (raw)
In-Reply-To: <m27fj1lhp0.fsf@discipline.rit.edu>
On Fri, Jan 22, 2016 at 11:09:15AM -0500, Andrew W Elble wrote:
>
> > By the way, is the only problem is that the client is trying to do
> > krb5i/krb5p on an export exported only with sec=sys or sec=krb5?
>
> Barring anything else I missed, yes.
>
> > So for example we could allow krb5i/krb5p on any compound containing an
> > so_must_allow op?
>
> This was roughly my reasoning/question...
Right, so I guess I've convinced myself to stop worrying as much about
whether your nfsd4_spo_must_allow allows too much.
In fact I wonder if it'd be simpler just to skip the OP_IS_PUTFH_LIKE
checks and just set spo_must_allowed on any compound with any must_allow
op in it.
At worst we've allowed use of krb5p/krb5i for a few ops on filesystems
that don't allow those, but who cares.
It doesn't bypass filesystem permission checks on operations that do
permission checks, and you still might consider removing that fh_verify
from DELEGRETURN in a separate patch. And the client may still have
some trouble with filesystems that do permission checks on GETATTR.
--b.
next prev parent reply other threads:[~2016-01-22 16:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 20:08 [PATCH v2 0/3] Deal with lost delegations and EKEYEXPIRED Andrew Elble
2016-01-18 20:08 ` [PATCH v2 1/3] nfs/nfsd: Move useful bitfield ops to a commonly accessible place Andrew Elble
2016-01-18 20:08 ` [PATCH v2 2/3] nfsd: allow mach_creds_match to be used more broadly Andrew Elble
2016-01-18 20:08 ` [PATCH v2 3/3] nfsd: implement machine credential support for some operations Andrew Elble
2016-01-20 22:53 ` J. Bruce Fields
2016-01-21 16:07 ` J. Bruce Fields
2016-01-21 19:01 ` J. Bruce Fields
2016-01-21 19:30 ` Andrew W Elble
2016-01-21 19:50 ` J. Bruce Fields
2016-01-22 0:01 ` Andrew W Elble
2016-01-22 15:24 ` J. Bruce Fields
2016-01-22 16:06 ` Trond Myklebust
2016-01-22 15:40 ` J. Bruce Fields
2016-01-22 16:09 ` Andrew W Elble
2016-01-22 16:36 ` J. Bruce Fields [this message]
2016-01-20 22:34 ` [PATCH v2 0/3] Deal with lost delegations and EKEYEXPIRED J. Bruce Fields
-- strict thread matches above, loose matches on Subject: below --
2016-01-05 18:55 Andrew Elble
2016-01-05 18:55 ` [PATCH v2 3/3] nfsd: implement machine credential support for some operations Andrew Elble
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=20160122163620.GD9082@fieldses.org \
--to=bfields@fieldses.org \
--cc=aweits@rit.edu \
--cc=dros@primarydata.com \
--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 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).