Re: [nfsv4] New Version Notification for draft-bhalevy-nfs-obj-00.txt

["Haynes, Tom" <[e-mail]>]

On Oct 14, 2012, at 7:30 AM, Benny Halevy <[e-mail]> wrote:

> On 2012-10-11 20:58, Haynes, Tom wrote:
> 
> <snip>
> 
> 
>>>> What are holes?
>>> 
>> 
>> I know what holes are, my point is that you are using it without definition.
>> 
> 
> I presumed it's common knowledge in the storage community but I can take a stab
> at defining holes more clearly.
> 
> <snip>
> 

I think the biggest disconnect for me was that the text shifted to the client
interacting with the application without an introduction. It was not clear
who was generating the holes and who they were being sent to.

Anyway, you should point out that this behavior is specific to the OSD
data servers as holes cannot be sent along earlier versions of NFS.

<snip>



> 
>> the management of
>>   state required by the storage devices to perform client access
>>   control
> 
> SETATTR + out of band manipulation of NFS exports properties.
> 


And depending on the implementation of caching of the exports,
this can impose performance penalties on the other clients.

The larger problem with this is that the access control needed are
 per file, not per filesystem. And unless the NFS server supports
per file exports, this approach fails to meet requirements.

<snip>

> 
>> 
>> Also, once NFSv4.2 drops into place, how will this proposal handle
>> Labeled NFS?
>> 
>> 
> 
> It is optional for the server to support labeled NFS


For NFSv4.2 it is optional, it could be made mandatory for NFSv4.3.


> draft-ietf-nfsv4-minorversion2-15 puts the burden on the client:
> 7.3.2. Permission Checking:
>   NFSv4 should defer permission checking on this attribute to the host
>   system.  These checks are performed in addition to existing DAC and
>   ACL checks outlined in the NFSv4 protocol
> 
> 7.3.5. Label Changes:
>   Consider a system in which the clients enforce MAC checks and and the
>   server has a very simple security system which just stores the
>   labels.  In this system, the MAC label check always allows access,
>   regardless of the subject label.
> 
> 7.4. pNFS Considerations:
> 7.4.1. MAC Label Checks
>   The new FATTR4_SEC_LABEL attribute is metadata information and as
>   such the DS is not aware of the value contained on the MDS.
>   Fortunately, the NFSv4.1 protocol [2] already has provisions for
>   doing access level checks from the DS to the MDS.  In order for the
>   DS to validate the subject label presented by the client, it SHOULD
>   utilize this mechanism.
> 
> This ability is specific to the files layout and to the proprietary
> control protocol.  What can be said in our case is that when there is
> such a protocol in place, it SHOULD be used to enforce MAC labels checks.
> 


Why is it specific to the files layout?

This is the kernel of my contention with the way pNFS as described by
5661 works with different layout models. 5661 has requirements placed
outside of the layout model - the requirement for a Control Protocol is
one such.

I've been assuming all along that the blocks and object based layouts
took care of this issue by the storage devices being part of an array 
or cluster. And they communicated to solve these issues.

If they do not, then I do not consider them to be compliant to 5661.