Subject: Re: [nfsv4] open share modes and file permissions

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 6 Jan 2010 11:57:24 -0500

On Mon, Dec 14, 2009 at 11:16:58AM -0500, J. Bruce Fields wrote:
> On Fri, Nov 13, 2009 at 12:46:39PM -0500, bfields wrote:
> > Forgive me if this has been discussed before.
> > 
> > Should a client need particular file permissions in order to open with
> > DENY bits?  Does anyone know what the Windows behavior is, and what
> > other server implementations do?
> > 
> > (The linux server is almost certainly wrong--it's requiring write
> > permissions for DENY_WRITE but not for DENY_READ.)
> 
> To answer my own question--looks like the Windows behavior is to require
> write permissions for DENY_READ, and that's what I'm fixing the Linux
> server to do.

(But it's been pointed out to me that I missed something: windows
doesn't enforce this by returning a permissions error on open; instead,
it allows the open to succeed, and just ignores any read deny bit.)

--b.

---

From: Rick Macklem <[email-masked]>
Date: Wed, 6 Jan 2010 12:21:06 -0500 (EST)

> it allows the open to succeed, and just ignores any read deny bit.)
Ouch! Is that considered a feature or a bug? ;-) rick

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 06 Jan 2010 12:14:25 -0500

> Ouch! Is that considered a feature or a bug? ;-) rick

Furthermore, is it something that we want to copy in the NFSv4
protocols? If so, it must go into RFC3530bis, and into any future
NFSv4.1bis...

Trond

---

From: "Peter Varga" <[email-masked]>
Date: Wed, 6 Jan 2010 12:29:07 -0500

Shouldn't this be left up to the underlying file system - not the NFS
protocol?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Trond Myklebust
Sent: Wednesday, January 06, 2010 12:14 PM
To: Rick Macklem
Cc: J. Bruce Fields; [email-masked]
Subject: Re: [nfsv4] open share modes and file permissions

Trond

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 6 Jan 2010 09:49:10 -0800

I'm pretty sur NLM share locks behave as nfsv4 is literally specified, and
I haven't heard of ill effects.

I don't see any need to change nfsv4, but await evidence to contrary.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 06 Jan 2010 13:34:01 -0500

> Shouldn't this be left up to the underlying file system - not the NFS

There is no way for the application to figure out what the underlying
filesystem is, when running on NFS. If it really does need the deny
modes in order to work correctly, then how can it figure out whether or
not they have been applied if we allow filesystems to ignore them?

IOW: if applications need this, then we should have a protocol
definition that makes the behaviour predictable. If, OTOH, there are no
applications out there that have any dependencies on deny bits, then
they should just be dropped from the protocol entirely.

   Trond

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 6 Jan 2010 14:21:42 -0500

> definition that makes the behaviour predictable.  If, OTOH, 
> there are no applications out there that have any dependencies 
> on deny bits, then they should just be dropped from the protocol 
> entirely.

Whoa.

I don't think anyone has proposed allowing them to be ignored in
general.  What has been suggested is allowing them to be ignored when
done by somebody who has no right to apply them.  You don't want a guy
who only has read access to a file to be able to prevent everyone else
from reading the file.

So, for example, opening a file for WRITE with DENY=READ would have a
specified behavior, in all cases, that we have been talking about.  If
you don't have write access to the file, the open fails.

Opening for READ with DENY=READ is a kind of strange case and when done
by someone who has no right write the file, a sub-case of that.  I agree
that specifying the behavior is a abetter choice if possible, but if
that isn't possible (or is only a SHOULD) that doesn't make deny modes
useless. 

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Wednesday, January 06, 2010 1:34 PM
To: Peter Varga
Cc: J. Bruce Fields; Rick Macklem; [email-masked]
Subject: Re: [nfsv4] open share modes and file permissions

   Trond

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 6 Jan 2010 14:24:44 -0500

Worthwhile point but note that NLM share locks are advisory. They don't
stop people from actually reading the data, which means that the sets of
problems that you can run into might well be larger in the v4 case.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Wednesday, January 06, 2010 12:49 PM
To: Trond Myklebust
Cc: J. Bruce Fields; Rick Macklem; [email-masked]
Subject: Re: [nfsv4] open share modes and file permissions

I'm pretty sur NLM share locks behave as nfsv4 is literally specified,
and
I haven't heard of ill effects.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 06 Jan 2010 14:42:58 -0500

> who only has read access to a file to be able to prevent everyone else

Quite frankly, I think it's a mistake to allow anybody to deny access to
a file simply by opening it. However, since we're trying to make the
protocol Windows-friendly, we should try to do something that makes
sense to Windows applications.

If they don't expect an error in the case where they have the correct
share access permissions, but don't have share deny permissions, then
let's do that. Let's not invent something that won't work for Windows,
and that will just get in the way of POSIX applications.

> that isn't possible (or is only a SHOULD) that doesn't make deny modes

Sure, but one of the most common cases out there is to open for READ
with DENY=WRITE. What should be the semantics for that case?

Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 13 Jan 2010 15:18:22 -0500

> with DENY=WRITE. What should be the semantics for that case?

My impression is that that's always allowed, and that it's only the READ
with DENY=READ that requires write permissions.

So I agree with Dave, this sounds like a small point.

(On the other hand: the Windows behavior of just silently ignoring the
DENY_READ might make this worth documenting, just because I have a
sneaking suspicion that:

	1. there probably are Windows applications that routinely do
	   exclusive opens, even if they don't need to.  (Hey, it's
	   easy: you just stick a "0" in CreateFile's "sharemode"
	   argument, and you may never see that cause any problem in
	   real use, especially since Windows has always done you the
	   favor of ignoring that when it doesn't make sense....)

	2. Server implementors that don't know Windows intimately but
	   think "hey, letting anyone deny read access to a file is
	   probably a bad idea" are likely to do it by returning a
	   permissions error.

Then one day the applications of 1. encounter the server of 2. and the
hilarity ensues.)

--b.

---

From: "Goldick, Jonathan" <[email-masked]>
Date: Wed, 13 Jan 2010 13:58:13 -0700

I've been working in Windows for some time and I've never heard about NTFS requiring specific privileges in order to set a DENY mode of any stripe.  The logic as I remember it is as long as you can open the file for read, or write, or delete access you can set any restrictions you want.  If you don't open the file for such access, like opening using only FILE_READ_ATTRIBUTES the share modes are ignored completely.  If someone can point to a reference for the NTFS protection model described below I'd sure like to see it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Wednesday, January 13, 2010 12:18 PM
To: Trond Myklebust
Cc: Rick Macklem; Noveck, Dave; [email-masked]
Subject: Re: [nfsv4] open share modes and file permissions

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 13 Jan 2010 16:40:07 -0500

On Wed, Jan 13, 2010 at 01:58:13PM -0700, Goldick, Jonathan wrote:
> I've been working in Windows for some time and I've never heard about
> NTFS requiring specific privileges in order to set a DENY mode of any
> stripe.

As I said, the behavior is to allow the open, but silently fail to
enforce the deny--behavior you're unlikely to have noticed by accident.

> The logic as I remember it is as long as you can open the
> file for read, or write, or delete access you can set any restrictions
> you want.  If you don't open the file for such access, like opening
> using only FILE_READ_ATTRIBUTES the share modes are ignored
> completely.  If someone can point to a reference for the NTFS
> protection model described below I'd sure like to see it.

I've looked for documentation, but haven't been able to find it.

Apologies, I don't have code, but the test case is roughly:

	- open a file for read, with reads denied.
	- do another open for read.

The results reported to me are that if you do not have write permission
to the file, then both opens will succeed.  (Meaning that the read deny
is not actually enforced.)  If you have write permissions, the second
read fails.  I'm told this is by design.

If you test this, I'd be interested in results either way.  (And on what
Windows version you saw the results.)

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 13 Jan 2010 18:53:41 -0500

> read fails.  I'm told this is by design.

It doesn't appear to be documented, though. 

There is nothing in the official docs for CreateFile that state you need
any particular file permissions whatsoever in order to set the share
mode. The msdn documentation just states that _if_ the CreateFile
succeeds, then subsequent open calls will be denied if their access
modes conflict with your share modes (i.e. there is no mention of any
exceptions).

http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx

However, you should note that once the file has been opened "share for
read" or "share for write", then Windows appears to require the share
mode bits in subsequent open requests to not conflict with the access
mode for the existing open. See the table of "valid second calls to
CreateFile" in:

http://msdn.microsoft.com/en-us/library/aa363874%28VS.85%29.aspx

Again, there appears to be no mention of particular file permission
requirements (beyond those required for the open access mode). Nor does
there appear to be a mention of any exceptions to this table in which
the share modes on the second call would be ignored.

Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 13 Jan 2010 19:05:58 -0500

> the share modes on the second call would be ignored.

Yeah, I looked at all that and more and haven't found anything relevant.

--b.

---

From: "Peter Varga" <[email-masked]>
Date: Wed, 13 Jan 2010 22:41:00 -0500

Well I too am a Windows developer, and was surprised to see that what
Bruce is saying is in fact true. The documentation is not wrong - it's
simply not revealing this fact.

Simply create a test application that does this:

hFile1 = CreateFile(argv[1], GENERIC_READ, 0, NULL, OPEN_EXISTING, 0,
NULL);

hFile2 = CreateFile(argv[1], GENERIC_READ,
FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE, NULL, OPEN_EXISTING,
0, NULL);

Ensure that the account under which you're running the application has
only read access to argv[1] in the ACL. NOTE: achieve this by
manipulating the ACL, not by setting FILE_ATTRIBUTE_READONLY. You must
ensure the user doesn't have write access in the ACL itself.

Under this condition, you will see that the second CreateFile() call
succeeds. If the user has write access to argv[1], the second
CreateFile() fails as expected.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of J. Bruce Fields
Sent: Wednesday, January 13, 2010 7:06 PM
To: Trond Myklebust
Cc: Goldick, Jonathan; Rick Macklem; Noveck,Dave; [email-masked]
Subject: Re: [nfsv4] open share modes and file permissions

--b.

---

From: "Goldick, Jonathan" <[email-masked]>
Date: Wed, 13 Jan 2010 21:03:22 -0700

I believe what you are seeing is the impact of the SHI1005_FLAGS_RESTRICT_EXCLUSIVE_OPENS option in Windows.  See http://msdn.microsoft.com/en-us/library/bb525404(VS.85).aspx

This is an option added in win2k3 I believe that controls this behavior over CIFS.  I don't remember an analog in Win32 itself against a local disk.  MS added this to avoid the wonderful denial of service attacks we all worry about.  Basically the CIFS server adds in FILE_SHARE_READ if the application fails to request one of the following access rights

FILE_WRITE_ATTRIBUTES | FILE_WRITE_DATA | FILE_WRITE_EA | FILE_APPEND_DATA

-----Original Message-----

--b.

---

From: "Peter Varga" <[email-masked]>
Date: Wed, 13 Jan 2010 23:18:51 -0500

This is being done on a local NTFS partition - no CIFS involved.
Also, your reason doesn't explain why simply adding/removing write
access to the file modifies Windows' behavior.

It's clearly NTFS doing this since process monitor shows that the Win32
layer didn't modify the sharing mode bits.

-----Original Message-----
From: Goldick, Jonathan [mailto:[email-masked]] 
Sent: Wednesday, January 13, 2010 11:03 PM
To: Peter Varga; J. Bruce Fields; Trond Myklebust
Cc: Rick Macklem; Noveck, Dave; [email-masked]
Subject: RE: [nfsv4] open share modes and file permissions

I believe what you are seeing is the impact of the
SHI1005_FLAGS_RESTRICT_EXCLUSIVE_OPENS option in Windows.  See
http://msdn.microsoft.com/en-us/library/bb525404(VS.85).aspx

This is an option added in win2k3 I believe that controls this behavior
over CIFS.  I don't remember an analog in Win32 itself against a local
disk.  MS added this to avoid the wonderful denial of service attacks we
all worry about.  Basically the CIFS server adds in FILE_SHARE_READ if
the application fails to request one of the following access rights

FILE_WRITE_ATTRIBUTES | FILE_WRITE_DATA | FILE_WRITE_EA |
FILE_APPEND_DATA

-----Original Message-----
Of Peter Varga

-----Original Message-----

--b.

---

From: "Goldick, Jonathan" <[email-masked]>
Date: Wed, 13 Jan 2010 21:51:49 -0700

You are correct, I should have just tested this myself.

I don't know when this was added to NTFS but it's after I left the MS file systems group in 2000.  You'd think we could find a reference in the docs somewhere for a change of behavior like this.

One conclusion we could extract from this is that Windows applications better not assume exclusive opens prevent reading since we now have two examples from MS where that is silently overridden.

-----Original Message-----

--b.