ACL / SD support

Cole, Timothy D. timothy_d_cole at
Fri Feb 18 19:34:46 GMT 2000

> -----Original Message-----
> From:	Dan Kaminsky [SMTP:effugas at]
> Sent:	Thursday, February 17, 2000 10:14
> To:	Multiple recipients of list SAMBA-TECHNICAL
> Subject:	Re: ACL / SD support
> > so, if i get this straight, you think that by providing a generic,
> > combined, internal ACL API that it will make the job of mapping to
> > different ACL implementations easier???
> > 
> > how so???  let me get this straight.  you are proposing this, yes?
> > 
> > windows->sec_desc->internal_acl->trad_unix
> > windows->sec_desc->internal_acl->hpux_acl
> > windows->sec_desc->internal_acl->solaris_acl
> > windows->sec_desc->internal_acl->posix_acl
> > windows->sec_desc->internal_acl->sec_desc (native NTFS support)
> > 
> > is this correct?  because if so, what's the point of hte internal_acl
> bit?
> > if you can answer this question, i will stop asking it.
> Luke,
> 	Some central scheme is required.  Almost all language translation
> systems out there use an internal "pseudolanguage"(think esperanto) for
> translating from one context to another.
> 	Now, if that scheme can be contained within the sec_desc,
> great.  That means you have a way of conveniently representing sec_desc
> internally in a manner that allows functionality beyond that which is
> contained within the underlying file system.
	I've got some code written here for just such a generic ACL facility
(IMO, it really plays a similar role to the sys_* calls in Samba --
abstracts the "native" interface to something more or less generic, while
still close to the native interfaces), but I need to clear it with legal
before I can release it.

> 	I'm no expert when it comes to SMB, but I have the off feeling
> that NT SD's and English are similarly ornery, and both are more
> accurately contained within a "boiled down" internal_acl.
	Well, from my own experimentation, the possible "native"
representations are all enough alike that a pretty simple generic
representation will handle them.  Once you throw NT ACLs into the mix,
though...  you basically have to reconcile yourself to using NT ACLs where
it's appropriate, and then providing a generic API and ACL representation
for native kernel objects.

> 	Look.  Using the underlying file system is great for speed, but is
> pretty lousy for flexibility.  You have the same problem as when mail
> systems require a matching Unix user account for every single user they
> provide mail services for--just because I want someone to be able to check
> mail off me doesn't mean they should get *any* other form of identity on
> my system!
> 	I admit, I'm not really sure where we should go from
> here.  Honestly, we're starting to get the UMSDOS style problem of
> embedding more permissions into the file system than it can support
> directly.  
	Then we have to embed explicit access checks throughout Samba, which
will destroy performance.  Although userspace checks are unavoidable for
non-kernel objects, permissions checks on native kernel objects MUST be left
to the kernel.

More information about the samba-technical mailing list