--------- Received message begins Here ---------
>
> Jesse Pollard writes:
> > "Albert D. Cahalan" <acahalan@cs.uml.edu>:
> >> Michael Gerdts writes:
>
> >>> When implementing ACL's please read over section 5.9 of the NFSv4 draft.
> >>> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-07.txt
> >>>
> >>> By designing ACL's (and other things) to work well with NFSv4 from the
> >>> start, reiserfs will likely have a leg up on the competition inside and
> >>> outside of the Linux arena for being able to support NFSv4.
> >>
> >> Wow, that is almost pure NT 4.0, with 4 of 7 authors being from Sun!
> >> The only difference is that the 17 access mask bits are all specific;
> >> there is no concept of mapping generic bits to object-specific bits.
> >> The inheritance, types, and scanning algorithm are all from NT.
> >>
> >> This is a good system; it can handle Coda and Netware fairly well.
> >>
> >> Well, there you go. Windows NT features are required for UNIX now.
> >> Fortunately it isn't too late for Reiserfs and ext2. JFS seems to
> >> have a few interesting bits already, due to the OS/2 port. XFS will
> >> need to be dragged out of the dark ages of withdrawn POSIX drafts.
> >> UFS has several incompatible ACL flavors already, from Sun, Digital...
> >
> > ACLs over NFS is much older than that. I've been using them for at least
> > the last 10 years with Cray UNICOS servers and clients. I even (vaguely)
> > remember ACLs being available under Trusted SunOS over NFS (both client
> > and server had to be Trusted SunOS).
>
> Well, "both client and server had to be" doesn't count very much.
Same as with NT - both client and server have to be NT...
> > It isn't just a property of NT.
>
> Oh yes this is. I don't merely refer to NFS with ACLs. Hell, NT doesn't
> do NFS by default. I mean an NFSv4 ACL is structured like an NT ACL.
> The inheritance, types, and scanning algorithm are all from NT.
> See http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-07.txt and
> the online NT developer documentation; compare them yourself.
>
> NFSv4 ACLs are not just rwx permissions. Instead of those 3 bits,
> you get 17 bits. Here they are:
(UNICOS permissions weren't just rwx - those were the most frequently
used permissions though)
> READ_DATA read the data of the file
> LIST_DIRECTORY list the contents of a directory
> WRITE_DATA modify the file's data
> ADD_FILE add a new file to a directory
> APPEND_DATA append data to a file
> ADD_SUBDIRECTORY create a subdirectory to a directory
> READ_NAMED_ATTRS read the named attributes of a file
> WRITE_NAMED_ATTRS write the named attributes of a file
> EXECUTE execute a file
> DELETE_CHILD delete a file or directory within a directory
> READ_ATTRIBUTES read basic attributes (non-acls) of a file
> WRITE_ATTRIBUTES change basic attributes (non-acls) of a file
> DELETE Delete the file
> READ_ACL Read the ACL
> WRITE_ACL Write the ACL
> WRITE_OWNER change the owner
> SYNCHRONIZE access file locally at the server with sync read/write
>
> Where do you think SYNCHRONIZE and WRITE_OWNER come from? NFSv4 also
> has inherit-once ability, under the ACE4_NO_PROPAGATE_INHERIT_ACE name.
> NFSv4 even has 10 well-known identifiers and audit ACEs.
synchronize from the sync system call, write_owner from the chown system
call - which, by the way, is a resource control problem and has to be/should
be disabled on most systems (especially those with quota limits). Several
others trace all the way back to Multics.
Most of these are POSIX ACLs. The ones I'm not familar with are the ADD_
capabilities. This was usually covered by the ACL attached to the directory
by write permission. If I can write to the directory, then I can add/delete a
file or directory. Having separate entries could be usefull though and
can be a improvement.
BTW, where does the rename operation fit in? Does that require ADD_FILE
and DELLETE_CHILD ?
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:24 EST