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