Re: [nfsv4] Scribe 5/17

["J. Bruce Fields" <[e-mail]>]

On Tue, May 22, 2012 at 12:26:23PM -0700, Haynes, Tom wrote:
> On Tue, May 22, 2012 at 02:03:50PM -0400, J. Bruce Fields wrote:
> > On Sun, May 20, 2012 at 06:48:51PM -0400, Dave Quigley wrote:
> > > On 5/18/2012 4:27 PM, J. Bruce Fields wrote:
> > > >On Fri, May 18, 2012 at 03:28:58PM -0400, David Quigley wrote:
> > > >>For the usecases we have envisioned I don't think we would be
> > > >>sharing device nodes over NFSv4. I'm actually not sure what usecase
> > > >>would require that behavior. For reasonable SELinux enforcement on
> > > >>NFS mouted shares we'd want label notification on regular files,
> > > >>directories, and symlinks.
> > > >
> > > >OK.
> > > >
> > > >>I could comb through the other object
> > > >>classes which have a corresponding object type in NFS and make a
> > > >>better decision but I'd have to do that later when I get home from
> > > >>work.
> > > >
> > > >>From http://tools.ietf.org/html/rfc5661#section-5.8.1.2 :
> > > >
> > > >	o  NF4REG designates a regular file.
> > > >	o  NF4DIR designates a directory.
> > > >	o  NF4BLK designates a block device special file.
> > > >	o  NF4CHR designates a character device special file.
> > > >	o  NF4LNK designates a symbolic link.
> > > >	o  NF4SOCK designates a named socket special file.
> > > >	o  NF4FIFO designates a fifo special file.
> > > >	o  NF4ATTRDIR designates a named attribute directory.
> > > >	o  NF4NAMEDATTR designates a named attribute.
> > > >
> > > >>For now though I feel safe stating that those three object
> > > >>types I mentioned above would be sufficient for the dumb-server case
> > > >>as that case is mostly for labeling files and directories.
> > > >
> > > >--b.
> > > >
> > > 
> > > Ok so looking at that list it would be nice to have everything
> > > except named attribute directory and named attribute. We have object
> > > classes for all of the other types. You might want to allow labels
> > > on the named attrs though as well. We wouldn't make use of it but
> > > someone else might.
> > 
> > So at least for the selinux case, if I'm understanding you right:
> > 
> > 	- You *need* regular files, directories, and symlinks at a
> > 	  minimum.
> > 	- You don't need named attribute files and directories.
> > 	- The rest would be nice, but you could still live without them?
> > 
> > 
> > In any case, I assume that means we need label-change notifications for
> > those things.  And the current spec only handles that for the file case.
> > 
> > So we have to figure out how to handle directories and symlinks.  Tom
> > suggests we could handle directories by just adding language requiring a
> > server to notify clients that hold directory delegations.  We'd need to
> > look at that.  For symlinks we'd probably need more protocol?
> > 
> > --b.
> 
> Thanks for bringing this up. I think we really only care about things
> the client might have open state.

I assume you meant: "... only care about regular files that have open
state", but I'm nost sure.

That wouldn't agree with what Dave's said.

Looking at http://tools.ietf.org/html/draft-ietf-nfsv4-labreqs-03 it
says a couple different things:

	Servers MUST provide a mechanism for notifying clients of
	attribute changes of files on the server."

I'd be willing to take "files" to mean regular files, except the
sentence above says "Servers MUST be able to store and retrieve the
security attribute of exported files as requested by the client", and in
that case "files" was clearly meant to be all filesystem objects.

Then later for limited server mode it says "The server MUST inform
clients when an object label changes for a file the client has open."

So I don't know.

My concern is just that the authors may not have overlooked the fact
that in NFSv4 only regular files can be opened.  In which case we could
end up with something that doesn't actually work for their purposes.

--b.

> For the files, we only do the CB if the client has it open. If it
> does not, then when the client tries to access it, we will deny that.
> 
> For a directory, I see these scenarios:
> 
> 1) Delegation exists - CB
> 2) No delegation, but actively being used in a readdir - the NFSv4
>    ops will deny access
> 3) No delegation, client not "under" node - when crossing into the node,
>    access is denied
> 4) No delegation, client is under the node
> 
> In the last one, what are the expectations when the client tries to
> access a file/subdir inside the directory? With DAC, this is allowed.
> 
> For symlinks, I think we don't need a CB depending on the answer to 4) above.
> 
> -- 
> [e-mail], ex-cfb