Subject: RE: [nfsv4] ACLs and modes

From: [email-masked]
Date: Wed, 23 Aug 2006 13:29:56 -0400

>> -----Original Message-----
>> From: J. Bruce Fields [mailto:[email-masked]] 
>> Sent: Wednesday, August 23, 2006 13:16
>> To: Sam Falkner
>> Cc: [email-masked]
>> Subject: Re: [nfsv4] ACLs and modes
>> 
>> On Tue, Aug 22, 2006 at 09:49:56PM -0600, Sam Falkner wrote:
>> > So a fundamental question is, how do you "fix  up" an ACL to
>> > accomodate the new mode?
>> 
>> That's the wrong question.  Everyone wants a chmod to affect the ACL
>> somehow--after I do a
>> 
>> 	chmod 600
>> 
>> the server had better not permit anything to users other 
>> than the owner.
>> 
>> The tricky point is that some people want the sequence
>> 
>> 	chmod 600
>> 	chmod 644
>> 
>> to *restore* permissions that the ACL used to give to other users.

Do these people have a real business justification for this request,
or is it just because technically it would be neat to have ?

>> 
>> My position is: fine.  If you want to do that locally on the 
>> server, go
>> ahead.  If you want to actually expose the mechanism that 
>> you use to do
>> this stuff, to the point where you can even allow a client 
>> in the know
>> to do a read-modify-write in the middle:
>> 
>> 	chmod 600
>> 	getacl
>> 	setacl
>> 	chmod 644
>> 
>> and still get some permissions restored, then I'm OK with 
>> that too.  But
>> I am not willing to "tunnel" this extra information over the ACL
>> protocol itself.
>> 
>> If we're going to do this stuff, then we need entirely separate (and
>> optional) protocol mechanism for it, so we can ensure that only
>> consenting servers and clients ever have to see it.
>> 
>> --b.
>> 
>> _______________________________________________
>> 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: Sam Falkner <[email-masked]>
Date: Wed, 23 Aug 2006 14:36:04 -0600

On Aug 23, 2006, at 2:03 PM, J. Bruce Fields wrote:

> On Wed, Aug 23, 2006 at 01:29:56PM -0400, [email-masked] wrote:

> That's an excellent question.

Supposing it's not worth doing, then that's an even stronger argument  
for not adding a mask attribute to the protocol.

> By the way, I recently patched the Linux server to stop trying to
> transfer the mask over NFSv4.

Sounds like the ACLs you produce will be much simpler.  Are the ACLs  
produced more "Windows ACL GUI friendly"?

> That means we still restore permissions
> in the case above:
>
> 	chmod 600
> 	chmod 644
>
> We'd have to do extra work to avoid that behavior, since it's just  
> what
> our local filesystem does (and will probably continue to do even if
> native NFSv4 ACLs).
>
> The only thing we can't handle any more is stuff like
>
> 	chmod 600
> 	getfacl
> 	setfacl
> 	chmod 644
>
> because the mask information is lost in translation.  I can live with
> that for 4.1 too.

Sounds reasonable.

> Though as long as I've got a mask on my server's local filesystem (and
> we probably will, even in the native NFSv4 ACL case), I'd like to  
> have a
> way to expose it to clients that care.

I understand, but I think this would take some strong justification,  
rather than just "It'd be nice to have".

- Sam

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 23 Aug 2006 17:08:59 -0400

> produced more "Windows ACL GUI friendly"?

No, I only changed the setacl code; the ACLs I return are as annoying as
ever.  It's not the ACL GUI I'm most worried about, either; *I* can't
stand to read the things myself.

I want to change the returned ACLs too eventually, but that'll break
older Solaris and Linux client applications.  I think it's worth it
anyway, but I guess we should wait.

By the way, the new NFSv4->POSIX code looks promising (if I may say so
myself).  It maps any NFSv4 ACL to the *unique* (up to choice of mask
and inheritance flags) POSIX ACL that is closest without being more
permissive.  And it's not that much code, actually.  Updated draft and
sample code on the way soon....

(Any chance you could implement the same in UFS and any relevant client
libraries?  That'd make me feel a little better about ditching the old
ACL mapping completely.  Sample code available too.)

--b.

---

From: Sam Falkner <[email-masked]>
Date: Wed, 23 Aug 2006 15:33:32 -0600

> ACL mapping completely.  Sample code available too.)

Of course I can't say for certain, but yeah, there's a chance.  :-)   
Sorry I can't be more definitive yet.  I'm sure we'll talk about it  
in detail at Bakeathon.

- Sam

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 23 Aug 2006 16:03:00 -0400

By the way, I recently patched the Linux server to stop trying to
transfer the mask over NFSv4.  That means we still restore permissions
in the case above:

	chmod 600
	chmod 644

We'd have to do extra work to avoid that behavior, since it's just what
our local filesystem does (and will probably continue to do even if
native NFSv4 ACLs).

	chmod 600
	getfacl
	setfacl
	chmod 644

Though as long as I've got a mask on my server's local filesystem (and
we probably will, even in the native NFSv4 ACL case), I'd like to have a
way to expose it to clients that care.

--b.