From: Malahal Naineni <malahal@us.ibm.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: linuxnfs <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] nfs: handle servers that support either ALLOW or DENY ACE types.
Date: Fri, 24 Jan 2014 08:28:51 -0600 [thread overview]
Message-ID: <20140124142851.GA13421@us.ibm.com> (raw)
In-Reply-To: <979899AD-3AD6-4D89-B53F-1E30D4AB078B@primarydata.com>
Trond Myklebust [trond.myklebust@primarydata.com] wrote:
>
> On Jan 23, 2014, at 20:50, Malahal Naineni <malahal@us.ibm.com> wrote:
>
> > Currently we support ACLs if the NFS server file system supports
> > ALLOW and DENY ACE types. This patch makes the Linux client work with
> > ACLs if the server supports either ALLOW or DENY ACE types.
>
> According to RFC5661, the behaviour if you don’t have ALLOW aces is to deny all access. How does it make sense to accept that?
I have a server that only returned 'ALLOW' type support probably due to
a bug! There is nothing in the spec that said a server 'MUST' support
'ALLOW' and 'DENY' ACE types (RFC5661 does say 'SHOULD' though!). That
was my reasoning to fix the client to be more liberal/lenient.
Can a server implicitly construct 'ALLOW' ACEs based on mode and not
support explicitly setting such ACEs by a client? I am not too familiar
with ACLs, if you think we should only check for 'ALLOW' support flag, I
can re-spin the patch but I think it is better to be more lenient
specially if it is not incorrect by being more lenient!
Please let me know either way.
Regards, Malahal.
next prev parent reply other threads:[~2014-01-24 14:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 3:50 [PATCH] nfs: handle servers that support either ALLOW or DENY ACE types Malahal Naineni
2014-01-24 5:31 ` Trond Myklebust
2014-01-24 14:28 ` Malahal Naineni [this message]
2014-01-24 16:11 ` Trond Myklebust
2014-01-24 17:17 ` Malahal Naineni
2014-01-24 17:19 ` [PATCH] nfs: handle servers that support only ALLOW ACE type Malahal Naineni
2014-01-24 17:58 ` Trond Myklebust
2014-01-24 18:56 ` Malahal Naineni
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=20140124142851.GA13421@us.ibm.com \
--to=malahal@us.ibm.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.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