ACL / SD support

[Dan Kaminsky]

> 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'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.

	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.  

Yours Truly,

	Dan Kaminsky
	DoxPara Research
	http://www.doxpara.com