linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

      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).