Subject: [nfsv4] server-side open share implementation

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 20 Mar 2008 13:27:04 -0400

I was curious whether anyone (Solaris especially) could share any notes
on their server-side implementation of open share deny modes?

The linux implementation only enforces them in the server.  Some day we
might like to actually push them into the vfs so they could be enforced
properly against other users, but we haven't started that yet.

(Pointers to better forums to ask this sort of question also welcomed.)

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

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 20 Mar 2008 12:37:07 -0500

> (Pointers to better forums to ask this sort of question also  

Solaris had a share lock mechanism that the NFSv4 implementation used.
It does not yet fully integrate with local access but can be used
by other NFS versions and CIFS to have cross protocol interaction.

I can answer questions off-line if you like.

Spencer

---

From: Rick Macklem <[email-masked]>
Date: Thu, 20 Mar 2008 14:33:21 -0400 (EDT)

> The linux implementation only enforces them in the server.  Some day we

Ditto for my bsd server. They are only enforced against NFSv4 clients.
(Personally, since posix has no notion of open/share_deny, I can't see
  propagating them to local posix system calls?)

rick

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 20 Mar 2008 14:31:53 -0400

>  propagating them to local posix system calls?)

Yeah, perhaps not.  Trond reminds me that linux allows you to set a
"mandatory" flag on the flock() call, and that Samba (optionally) uses
this to enforce share locks.  That's imperfect.

By the way, a possibly stupid question: on a quick skim through rfc3530,
I can't figure out who's supposed to be permitted to do DENY opens.
Anyone?  Only users with write permissions?

--b.

---

From: Rick Macklem <[email-masked]>
Date: Thu, 20 Mar 2008 15:29:18 -0400 (EDT)

[stuff snipped]
> Anyone?  Only users with write permissions?
Actually, I'd say that's a good question (and not a stupid one). I allow
clients to Open/Deny by the same rules as I allow Open/Deny_none,
but I have no idea if that's correct? Sounds like a good question for the
Windows Wizards?

rick

---

From: "Peter Varga" <[email-masked]>
Date: Thu, 20 Mar 2008 15:42:47 -0400

> but I have no idea if that's correct? Sounds like a good question for

I just happened to glance at this e-mail :)

On Windows anyone can specify DENY bits. However, the access bits must
specify either READ_DATA or WRITE_DATA (i.e. not just READ_ATTRIBUTES),
otherwise the DENY bits get ignored (i.e. no access denied error). So,
indirectly, the caller must have READ_DATA and/or WRITE_DATA access to
the file for the deny bits to have effect.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 20 Mar 2008 15:45:59 -0400

> the file for the deny bits to have effect.

OK, but read-only access is all I need to prevent anyone from opening a
file indefinitely?

(If serving primarily posix clients that's behavior you might want
the server to have turned off by default!)

--b.

---

From: "Peter Varga" <[email-masked]>
Date: Thu, 20 Mar 2008 15:59:11 -0400

> > > but I have no idea if that's correct? Sounds like a good question
> for
> > > the
> > > Windows Wizards?
> > >
> > > rick
> > >
> >

Right, Win32 is not POSIX :)
The Windows answer here would be that an admin could determine the
process holding the file open and kill it ;)

The idea is to provide a simple way for an application to prevent the
file from changing while a user is using a process that reads in the
file as the user scrolls through it.

Win32 also imposes mandatory locking, in that a user who has placed a
read lock on a region of a file also prevents users with write access
from writing the locked region.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 20 Mar 2008 16:09:05 -0400

> Right, Win32 is not POSIX :)

Yeah, but this is terifically lenient, to the point of being a security
problem; all I have to do is send a single open for /etc/password, then
I can stall logins (at least) as long as I keep sending renews.

> process holding the file open and kill it ;)

Surely Windows environments also have files that always need to be able
to read, and occasional users that can't be trusted to be cooperative
(or careful)?

--b.

---

From: "Peter Varga" <[email-masked]>
Date: Thu, 20 Mar 2008 17:51:07 -0400

I just tested this out with Vista SP-1. Looks like this was far from a
silly question.
To my surprise, Windows has an undocumented behavior.

If a user doesn't have WRITE access, specifying DENY_READ gets ignored.
So a user with only read access cannot deny reading to others. Denying
writing does work though. Go figure.

Really gotta love how CreateFile() silently ignores my request to deny
read.

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]]
> Sent: Thursday, March 20, 2008 4:09 PM
> To: Peter Varga
> Cc: Rick Macklem; [email-masked]
> Subject: Re: [nfsv4] server-side open share implementation
> 
> > > > On Windows anyone can specify DENY bits. However, the access
bits
> > > must
> > > > otherwise the DENY bits get ignored (i.e. no access denied
> error).
> > > So,
> > > > indirectly, the caller must have READ_DATA and/or WRITE_DATA
> access
> > > to
> > > OK, but read-only access is all I need to prevent anyone from
> opening
> > a
> > > file indefinitely?
> > >

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 21 Mar 2008 11:12:58 -0400

> Really gotta love how CreateFile() silently ignores my request to deny

Weird.  So the open (or equivalent) succeeds, but the DENY is ignored.
(I wonder what happens if you modify the ACL to permit write to a user
already holding an open with DENY_READ?  I suppose it probably doesn't
affect anything until that user reopens?)

Should servers be advised to imitate that behavior?  Assuming the only
purpose of share locks is to support Windows applications, then I
suppose they probably should be.

--b.

---

From: "Peter Varga" <[email-masked]>
Date: Fri, 21 Mar 2008 14:57:18 -0400

> affect anything until that user reopens?)

Correct... no effect until I reopen.

> suppose they probably should be.
	
This behavior isn't documented anywhere in the CreateFile API:
http://msdn2.microsoft.com/en-us/library/aa363858(VS.85).aspx

It seems like a hack to handle the exact case you mentioned to prevent a
restricted user from blocking others from reading some files.