Subject: [nfsv4] Setting mode and not ACL tidbits

From: Benny Halevy <[email-masked]>
Date: Thu, 05 Jul 2007 10:51:26 +0300

Section 6.4.1.1 in draft-ietf-nfsv4-minorversion1-11 seem to me to be
a bit too restrictive.  The suggested model applies the group permission
bits on any entity other than the OWNER@ and EVERYONE@ ACEs. My problem
with it is that if the respective permission bits for MODE4_*OTH are set
the affected entities are allowed access via the EVERYONE@ ACE but
the information in the original ACE is lost.  Applying similar semantics
on the *OTH bits rather than on the *GRP bits just seem to make more sense
to me...

For example, how about the following text?

  If MODE4_ROTH is not set, entities explicitly listed in the ACL
  other than OWNER@ and GROUP@ SHOULD NOT be granted ACE4_READ_DATA.

rather than

  If MODE4_RGRP is not set, entities explicitly listed in the ACL
  other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_READ_DATA.

Benny

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 5 Jul 2007 11:35:53 -0400

> on the *OTH bits rather than on the *GRP bits just seem to make more sense

There's some strange posix requirements here:

After a chmod, permissions must be bounded above by the mode.  The group
bits are defined to cover the file's group and other
implementation-defined users, and the other bits are defined to cover
only users other than the owner and those covered by the group bits.

Uh, I guess we could restrict using the other bits instead of the group
bits without violating those rules.  I can't remember why we don't now;
I think it's just inconveniently restrictive in some situations.  Maybe
the spec could allow either.  Linux and Solaris implementations at least
are going to use group bits, though.

Other bits are virtually always more restrictive than group bits, so
nobody will actually care if you use the other bits instead.

Argh.  I have to go revisit the arguments here from scratch every time
this comes up.

--b.