On Tue, 31 Oct 2000, Stephen C. Tweedie wrote:
> Hi,
>
> > > > NFSv4 indeed specifies yet another variant of ACLs.
> > >
> > > Yep. In fact, it defines a richer environment than POSIX. However, I
> > > _think_ that for any POSIX ACL, you can define an NFSv4 list which is
> > > equivalent in all details (although the reverse is definitely not
> > > true).
> >
> > NFSv4 defines additional permissions.
> >
> > Unless I've missed something again, there's no mapping for Posix ACL_MASK
> > entries, though.
>
> Hmm --- given any POSIX ACL you can define an NFSv4 ACL which gives
> the same permissions, even including ACL_MASK, but you probably can't
> make one which has the same semantics on subsequent chmod()
> modifications of the group permissions bits.
It would indeed be possible to present the permissions defined in a POSIX
ACL as an NTFSv4 ACL by applying the ACL_MASK entry before constructing
the NFSv4 ACL. Subsequent chmod's would cause havoc, though. The whole
point in having the ACL_MASK entry is to ensure this sort of interaction
works "as expected".
I think constructing an NFSv4 ACL that cannot be translated back into an
identical POSIX ACL is pretty worthless. Maybe another special ACL entry
(like "MASK@") can be introduced. That would be a proprietary extension,
and the ACL semantics would derive from the semantics specified for NFSv4.
I feel pretty uncomfortable with NFSv4 ACLs. I really had extected NFSv4
to specify a standard format for manipulating various sorts of ACLs, but
not a new variant of them. I don't see this as an advantage. Most systems
will implement NFSv4 on top of other file systems, so NFS should allow to
manipulate the native ACLs. But that's just whining about the past; it
already has happened.
Andreas.
------------------------------------------------------------------------
Andreas Gruenbacher, [EMAIL PROTECTED]
Contact information: http://www.bestbits.at/~ag/
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
