Subject: RE: [nfsv4] Raw notes from today's ACL meeting

From: "Yoder, Alan" <[email-masked]>
Date: Wed, 9 Aug 2006 11:28:00 -0700

> Enable POSIX compliance

This needs to be optional to support if it involves any unnatural acts.

> - Bruce said to add: "Don't allow the the permissions to be more
permissive than what would be given when setting the mode."  This was
agreed to be a good thing. 

Caveat: as I said before, this can cause v2 clients to mistakenly
assume they can't access a file in some cases, when they actually could.
That's because you end up using a mode less permissive than the ACL,
if you've been told not to use one that's more permissive.
I'd like to see the standard allow more permissive modes in v2 stat
calls to work around this issue.

Cheers,

Alan  

> -----Original Message-----
> From: Lisa Week [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 9:42 PM
> To: [email-masked]
> Subject: [nfsv4] Raw notes from today's ACL meeting
> 
> Hi all,
> 
> Here are the raw notes taken from today's ACL design team meeting.
> 
> We will do a summary of the conclusions drawn from the 
> meetings after  
> Thursday's meeting (which is the last day).
> 
> I will be sending out another email shortly with the proposed agenda  
> for tomorrow.
> 
> Thanks,
> Lisa
> 
> 

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

---

From: Peter Staubach <[email-masked]>
Date: Wed, 09 Aug 2006 14:49:00 -0400

> calls to work around this issue.

Will this not allow some clients to incorrectly decide that access
should be permitted, this introducing a security issue?

It seems to me that denying access to a file is better than allowing
access incorrectly, unless the environment is known in advance.

    Thanx...

       ps

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 09 Aug 2006 18:00:44 -0400

> access incorrectly, unless the environment is known in advance.

In order to do this, the server would need for instance to take the ACE
for GROUP@ and then look for all DENY ACEs that apply to any single
member of that group, and apply them as a mask in order to create the
conservative "group" mode bits.

A similar process would need to be done for OWNER@ and EVERYONE@ in
order to create the conservative "user" and "other" mode bits.

Cheers,
  Trond

---

From: Eric Werme USG <[email-masked]>
Date: Wed, 09 Aug 2006 18:38:01 -0400

> Enable POSIX compliance

Alan  Yoder noted:

It may be worthwhile to consider NFS V2 an unnatural act.  (I just
noticed a bug yesterday in the "static pathconf kludge" that was in
ONC 4.2 and has faithfully shipped in Tru64 Unix since 1993.  Sigh.)

A problem in well behaved V2 clients is that the two levels of access
checking (mode bits on the client, anything at all on the server) isn't
always applied.  If someone with access to a file reads it, and the
data is left in the client cache, someone else who tries to read it
will have only the client mode check applied.  While this might
argue for the more restrictive bits, that leaves Alan's concern.
Recommend against caching V2 data?  Gack!  Warn people of the problem
and tell them to disable V2?

Stupid question of the thread:  How many people still use NFS V2?
And are they all Cobol programmers?  And please don't forget the Cobol
program that actually used "Unix file record locking" to lock offset
5-6 to refer to bytes 400-560.  (80 column fixed length records and all
that - as Ric types into his 80 column emacs window.)

	-Ric Werme