POSIX ACL support?

[Cole, Timothy D.]

> -----Original Message-----
> From:	Jeremy Allison [SMTP:jallison at cthulhu.engr.sgi.com]
> Sent:	Monday, October 11, 1999 13:15
> To:	Multiple recipients of list SAMBA-NTDOM
> Subject:	Re: POSIX ACL support?
> 
> Allan Bjorklund wrote:
> > 
> >     What happened with the abstracted ACL interface for SAMBA?
> > 
> >     We had that discussion on the list a few months back and I was
> > wondering if anyone is working on it.
> > 
> 
> That's pretty much what I'm talking about. I intend
> to implement that interface and provide sample implementations
> for the Linux POSIX ACL patch (which is close enough to
> the POSIX ACL support in IRIX and HPUX I believe that 
> autoconf should patch over the differences :-).
> 
	HP-UX has its own proprietary ACL scheme/API in addition to the
POSIX one provided by DCE, so it's not really that simple.  There's also the
matter of other non-POSIX ACL schemes, such as the one used by AFS.

	I've been working on a generalized ACL interface a _little_, but
other demands at my job have prevented me from touching it for more or less
the past month.  Basically the way it would ultimately work is that each
"ACL handler" would have an ACL_OPS struct, and register itself on startup
with acl_scheme_register()... for instance, the one for UNIX triads would
work something like:

	 ACL_OPS acl_unix_scheme = {
		acl_unix_detect, /* int (*detect)(files_struct *fsp) --
return true if UNIX triads
	                       supported by the indicated filesystem object
*/
		acl_unix_get, /* int (*get)(files_struct *fsp, ACL *acl) --
fill out the given ACL
	                    structure from the object's ACL */
	   acl_unix_check, /* int (*check)(files_struct *fsp, ACL *acl) --
return true, accepting
	                      the ACL as-is, or munge the ACL into something
directly representable
	                      in the underlying ACL scheme (in this case
Unix triads) */
	   acl_unix_set, /* int (*set)(files_struct *fsp, const ACL *acl) --
set the ACL; will
	                    blindly discard ACL information not
representable in the underlying
	                    scheme (the check function tries to be
intelligent about rewriting
	                    the ACL, however) */
	 };

	 static int acl_unix_detect(files_struct *fsp) {
		return 1; /* assume these, at least, are always supported */
	 }

	 static int acl_unix_get(files_struct *fsp, ACL *acl)
	 {
		int status;
		SMB_STRUCT_STAT sbuf;

		status = my_stat(fsp, &sbuf);
		if (!status) {
			acl->n_entries = 3;

			acl->entry[0].type = ACL_ENTRY_USER;
			acl->entry[0].uid = sbuf->st_uid;
			acl->entry[0].flags = ACL_ENTRY_IS_OWNER; /* more of
a "hint" */
			acl->entry[0].perms.allow = ( sbuf->st_mode >> 6 ) &
0007;
			acl->entry[0].perms.deny = 0;

			acl->entry[1].type = ACL_ENTRY_GROUP;
			acl->entry[1].gid = sbuf->st_gid;
			acl->entry[1].flags = ACL_ENTRY_IS_OWNING_GROUP;
			acl->entry[1].perms.allow = ( sbuf->st_mode >> 3 ) &
0007;
			acl->entry[1].perms.deny = 0;

			acl->entry[2].type = ACL_ENTRY_OTHER;
			acl->entry[2].perms.allow = sbuf->st_mode & 0007;
			acl->entry[2].perms.deny = 0;
		} else {
			DEBUG(0, ("acl_unix_get: stat of %s failed; error
%s\n", fsp->fsp_name, strerror(status)));
		}

		return status;
	 }

	etc etc..

	And on startup, the following would get called:

	acl_scheme_register("unix", &acl_unix_scheme);

	Similarly for other ACL schemes.  In smb.conf, a parameter for the
order of precedence for the schemes could get specified:

	 acl support = hpux posix afs unix

	So, when an ACL was queried for an object, given its fsp, the
detect() functions would be tried for each ACL scheme in turn and then the
get() function called for the first one detected. Alternatively, in that
case maybe just try the get() functions, and use the first one that
succeeds; the detect logic should probably still be there for some other
cases, though).

	The appropriate ACL_OPS for a particular fsp can be cached in the
fsp, _iff_ fsp->fd_ptr, else a symlink or a fresh mount could change the ACL
scheme in effect.

	When that can't be cached, acl_get() need to try each of the get()
functions in turn every time when querying the ACL.

	Similarly, when cacheing isn't possible, acl_check() and acl_set()
each have to rely on querying the detect() functions, if the ACL_OPS cannot
be cached.  Although maybe set operations could get away with walking down
the possible set()s...

	A lot of this complexity is necessary, since ACL schemes in effect
can and will vary across different portions the filesystem hierarchy, and
some ACL schemes (like unix) will always at least _seem_ to work, even if
some other scheme like AFS is present over top of them, so the "higher
precedence" ones always need to be tried first.

	One possible problem is if the underlying ACL scheme changes between
an acl_check() and an acl_set()... I'm not really sure how to handle that
case.  Additionally, I'm not sure how this would interact with the VFS
stuff.

	Um... ow.  that was much longer than I had intended.  Anyway,
thoughts?  I might be able to spend a little time on this this week.