ACL / SD support

Luke Kenneth Casson Leighton lkcl at samba.org
Wed Feb 16 20:30:35 GMT 2000


> > what i don't get is why you want to convert from security
> descriptors to a
> > new, intermediate, internal API that has to support both a maximum
> _and_ a
> > minimum of the functionality provided _by_ security descriptors, it
> > doesn't buy you anything.
> >
> > does it?
> 
> Yes, you don't need to create one samba for HPUX, one for Solaris, one
> for Linux, and what you propose to do for those with several kinds of
> file systems on the same computer, I don't know. You cannot convince
> me that this would be better and/or easier.

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.

[i can actually think of a reason, i'm curious to see if you think
likewise]



More information about the samba-technical mailing list