generic ACL interface (RFC)

[Cole, Timothy D.]

> -----Original Message-----
> From:	Jean Francois Micouleau [SMTP:Jean-Francois.Micouleau at dalalu.fr]
> Sent:	Tuesday, July 27, 1999 17:27
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	Re: generic ACL interface (RFC)
> 
> On Wed, 28 Jul 1999, Cole, Timothy D. wrote:
> 
> > typedef struct acl_entry_info {
> > 	ACL_ENTRY_TYPE type;
> > 	int32 flags;
> > 	uid_t user_id;
> > 	DOM_SID user_sid;
> > 	gid_t group_id;
> > 	DOM_SID group_sid;
> > 	struct {
> > 		int32 allow;
> > 		int32 deny;
> > 	} perms;
> > } ACL_ENTRY;
> 
> why do you want to mix uid/gid and sid in the ACL_ENTRY ? If the structure
> is representing the POSIX theorical view, only Unix informations should be
> in.
> 
	It's basically supposed to be a middle ground between the client's
view and a very generalized "UNIX" one, where no additional information gets
lost.  The POSIX theoretical view is unfortunately too limited to accomodate
even all of the Unix variations (i.e. HP-UX's).  The ACE may contain
information that Samba's host environment doesn't understand, or information
that the client doesn't understand, depending on where it came from.

> And some rid<->uid/gid functions already exist in samba.
> 
	The dual uid/gid + suid thing is there for situations where there
may be a specific SID associated with the ACL, but not a user id to go with
it (unless all of the unmapped SIDs are squashed to root or something).
ACLs returned from the client, for instance.

	If for some reason the underlying fs thinks in terms of SIDs (say, a
future version of smbfs with ioctls() like those of the Linux NTFS driver),
you don't want to throw that information out.  (not knowing much about the
NTFS driver, this could be a completely bogus argument, though)

	My intent wasn't to replace/rewrite the rid<->uid/gid mapping
functions, but I figured it wouldn't hurt to hang onto both the uid and the
sid to save having to do multiple lookups for the same ACE, or losing
information in cases where there was no mapping.  (then again, it's not like
these are horribly frequent or intensive operations, so it may not be worth
the bother)

	I dunno; I guess I'll try a first implementation without the SIDs,
as you suggest.

> > /* what should the return values mean here? */
> > extern int get_acl(files_struct *fsp, ACL_ENTRY **entries, int
> *n_entries);
> > extern int set_acl(files_struct *fsp, const ACL_ENTRY *entries, int
> > n_entries);
> > extern void free_acl(files_struct *fsp, ACL_ENTRY *entries);
> 
> why ACL_ENTRY directly ? How do you know the file owner with only
> ACL_ENTRY ?
> 
	Well, at the time I was thinking of using the (otherwise unused) uid
field in an ACL_ENTRY_IS_OWNER entry.

> I would go one step further and define:
> 
> typedef struct acl {
> 	uid_t owner_uid;
> 	gid_t owner_gid;
> 	ACL_ENTRY **entries;
> } ACL;
> 
> that would be closer to what is at least in HPUX.
> 
	Actually it's closer to POSIX/Solaris than to HP-UX; HP-UX will
report the uids and so forth in the base entries, although POSIX considers
the base entries a special case and doesn't.

	My first draft actually had the separate ACL structure, but then I
realized that the uid fields in ACL_ENTRY_IS_OWNER entries could be used
isntead, and those need to be filled out for the NT client's benefit anyway.

	Actually I'm still wondering if I shouldn't just go with the
rpc_secdes.h structures...