From: Boris Z. (boris@conley.com)
Date: 08/20/98-06:01:00 PM Z
Message-ID: <01BDCC53.BA2FAB40.boris@conley.com>
From: "Boris Z." <boris@conley.com>
Subject: RE: NFSv4: Identifying users & groups (Fwd)
Date: Thu, 20 Aug 1998 16:01:00 -0700
On Thursday, August 20, 1998 12:29 PM, Brent Callaghan [SMTP:Brent.Callaghan@eng.Sun.COM] wrote:
> > From boris@conley.com Thu Aug 20 12:18:42 1998
> > To: "'Brent Callaghan'" <Brent.Callaghan@Eng>
> > Cc: "nfsv4-wg@sunroof.Eng.Sun.COM" <nfsv4-wg@sunroof.eng.sun.com>
>
> > If the owner is a group, it can be encoded in the owner's field.
> > As Carl correctly pointed in NTFS we can associate many ACLs
> > (group's or user's) with a file.
>
> More precisely: a file can have only one ACL that may comprise
> many ACE's (Access Control Entries). Each ACE has a type field,
> user or group id field, and permission bits.
>
> > However, we need totally new way of expressing this ( GET_ACLS(cfh) ? )
>
> Rather than have an operator to get/set ACLs it would be more convenient
> to treat an ACL as a file attribute (as owner/group/permbits are now).
> Then you could have READDIR return ACLs for each entry if you really
> wanted.
>
> However, before we get too deeply into ACLs there's the problem of
> resolving the different ACL models: POSIX, DCE/DFS and NT. All
> very similar yet slightly different in their properties. I'd
> be grateful for any insightful proposals that would make these
> ACLs interoperable.
>
> Brent
>
>
>
Can we adopt an approach similar to the approach we have when deal with file systems -
design protocol's own semantics of ACLs? After all we have to define File System ACL.
For example, we can say that our ACE is:
struct ace {
user_name user; // string
bool granted; //if false - revoked
uint32 access; // access bits r,w,m,d and may be more... Only bits set to 1 are respected.
}
and package them together into ACL similarly to file entries in readdir.
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:13 AM Z CST