Subject: RE: [nfsv4] ACL discussion wrapup

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 6 Dec 2006 17:23:52 -0800

Mario and Bruce,

All of the proposed Retention stuff is optional (or supposed
to be).  Filesystems that don't do "compliance" don't
need it, I wouldn't think.

The problem we are trying to solve is to line up NFS
with the developing XAM retention model.  SNIA needs
this to enable practical implementations of a filesystem
interface (FSI) to XAM-compliant CAS systems.

Mario, David Black, who is one of the authors of this 
proposal, should be able to fill you in on EMC's interest
in this.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================

> -----Original Message-----
> From: Mike Eisler [mailto:[email-masked]] 
> Sent: Tuesday, December 05, 2006 1:41 PM
> To: [email-masked]
> Subject: RE: [nfsv4] ACL discussion wrapup
> 
> 
> --- [email-masked] wrote:
> 
> > I am not sure whether Windows has these bits, and I don't understand
> > what problem are we trying to solve with these bits.
> 
> Last summer, I proposed a very modest set of changes, but
> feedback from SNIA was that we needed something more complex,
> hence the current state of Retention. If the consensus is that
> we need something simpler, that's fine with me. Someone make a
> proposal.
> 
> > 
> > Mario
> >  
> > 
> > -----Original Message-----
> > From: J. Bruce Fields [mailto:[email-masked]] 
> > Sent: Tuesday, December 05, 2006 14:19
> 
> > By the way, on the new ACE4_WRITE_RETENTION and
> > ACE4_WRITE_RETENTION_HOLD mask bits: is a 4.1 server required to
> > support
> > them?  (Can a server return NFS4ERR_ATTRNOTSUPP to a setattr that
> > attempts to set an ACL using with one of these bits set?)
> > 
> > Do comparable bits exist in Windows ACLs?
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 7 Dec 2006 13:19:58 -0500

> need it, I wouldn't think.

Yeah, that's good.

I'm not trying to block the retention changes; I just want to make sure
we have whatever language is needed to be sure implementations
interoperate in the face of more optional ACE mask bits.

I wonder it'd be worthwhile to have a file attribute like:

	aclsupport2 {
		aceflag4 supported_flags;
		acemask4 supported_access_mask;
	}

and then require the server to accept *any* legal ACL (even if it used
unsupported bits), but take the aclsupport2 attribute as a disclaimer
allowing the server to silently modify and/or ignore any of the
unsupported bits.

It could then be left to the particular client or application to decide
how to strike the balance between convenience and security.  An ACL
editor gui could grey out those bits.  A commandline getfacl command
could print them with a warning that they're unsupported.  A
permission-preserving "cp" could fail, print out a warning, or just
silently allow them.  (Honestly, I'd be tempted to go with the latter.)

A careful server might still want to reject some unenforceable ACLs from
4.0 clients on the theory that they couldn't know about aclsupport2, but
it might be more lenient with 4.1 clients.

--b.