From: "J. Bruce Fields" <bfields@fieldses.org>
To: iisaman@umich.edu
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 2/2] remove open share mode file permission check
Date: Mon, 16 Aug 2010 20:45:47 -0400 [thread overview]
Message-ID: <20100817004547.GF7764@fieldses.org> (raw)
In-Reply-To: <20100817003802.GE7764@fieldses.org>
Both of these are also available from
git://linux-nfs.org/~bfields/pynfs.git
--b.
On Mon, Aug 16, 2010 at 08:38:02PM -0400, J. Bruce Fields wrote:
> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> First, the ability to deny reads is generally considered stronger than
> the ability to deny writes, so if anything should require special
> permissions it is the former.
>
> Second, this test contradicts observed Windows behavior. Testing shows
> that Windows prohits an opener without write permissions from denying
> reads. It will allow such an open, but will then also allow concurrent
> read opens, failing to enforce the DENY_WRITE.
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
> ---
> lib/nfs4/servertests/st_open.py | 21 ---------------------
> 1 files changed, 0 insertions(+), 21 deletions(-)
>
> diff --git a/lib/nfs4/servertests/st_open.py b/lib/nfs4/servertests/st_open.py
> index 64deb9f..1e5ec70 100644
> --- a/lib/nfs4/servertests/st_open.py
> +++ b/lib/nfs4/servertests/st_open.py
> @@ -347,27 +347,6 @@ def testShareConflict1(t, env):
> "Trying to open a file with deny=WRITE "
> "that was already opened with access=WRITE")
>
> -# FRED - is this right response? or should it be allowed?
> -def testShareConflict2(t, env):
> - """OPEN with deny=write when don't have write permissions
> -
> - FLAGS: open all
> - DEPEND: MKFILE MODE
> - CODE: OPEN19
> - """
> - c1 = env.c1
> - c1.init_connection()
> - c1.create_confirm(t.code, attrs={FATTR4_MODE:0644},
> - access=OPEN4_SHARE_ACCESS_READ,
> - deny=OPEN4_SHARE_DENY_NONE)
> - c2 = env.c2
> - c2.init_connection()
> - res = c2.open_file(t.code, access=OPEN4_SHARE_ACCESS_READ,
> - deny=OPEN4_SHARE_DENY_WRITE)
> - check(res, NFS4ERR_ACCESS,
> - "Trying to deny write permissions to others when "
> - "don't have write permissions")
> -
> def testFailedOpen(t, env):
> """MULTIPLE: failed open should not mess up other clients' filehandles
>
> --
> 1.7.0.4
>
prev parent reply other threads:[~2010-08-17 0:47 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-17 0:37 [PATCH 1/2] TESTS: Allow server to reject commits with large offsets J. Bruce Fields
2010-08-17 0:38 ` [PATCH 2/2] remove open share mode file permission check J. Bruce Fields
2010-08-17 0:45 ` 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=20100817004547.GF7764@fieldses.org \
--to=bfields@fieldses.org \
--cc=iisaman@umich.edu \
--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).