ACL / SD support

[Luke Kenneth Casson Leighton]

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

the only reason to consider reinterpreting sec_desc to inernal_acl is to
make people feel more comfortable with the concepts involved.  i.e you put
unixy-stuff in it, like uids and gids, not SIDs.

well, you can put that sort of thing behind function calls.
 
> 	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.

personally, i wouldn't trust any "boiled down" system.  i'd like to see
the minimal amount of coding done for this, :

sec_desc->trad_unix
sec_desc->hpux_acl
sec_desc->posix_acl
sec_desc->sec_desc (direct to disk)

> 	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!

not at all.  not in samba.  every single user has a one-to-one
correspondance between SIDs and uids.  if there's no mapping between uids
and SIDs for any instance of SID or uid, that user is BANNED, period.

this is why i have such a problem with jeremy's insistence on supporting
the one-domain-only SURS algorithm.  even the BUILTIN domain is dropped.

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

no we're not.

any permissions not supported by the underlying file system are just
dropped from the SD.

this is why there's no point in having anything more or less than an SD
(or an exact SD equivalent, therefore what's the point of using anything
other than an SD).

am i way off, here?