ACL / SD support

[Michael Stockman]

Hello,

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

I'm not saying that the mapping will be easy. I'm saying that
everything else will be easier, because the mapping has equalized the
ACL so that we can ignore platform issues. Also, it is structurally
correct to have mapping functions which will make the code more
flexible and adaptable to new environments.

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

No. Actually more like this:

sec_desc->internal_acl->aces

read_trad_unix_sd( &sec_desc, ... )
read_solaris_sd( &sec_desc, ... )
read_hpux_sd( &sec_desc, ... )
...
read_nt_sd( &sec_desc, ... )
with corresponding write functions
I suppose that these could be called by a vfs_module when needed, or
by the parsing code. Supposedly even those who want to implement an
ACL system on top of the built in security system (on a machine only
accessed from samba) could do so and not end up with a complete mess
(although I've already stated that this is not a target with doing
this properly, just a consequence and should/will never end up in
samba AFAIK).

make_sd( ... )
make_inherited_sd( ... )
make_acl( ... )
acl_add_ace( ... )
acl_add_ace( ... )
acl_add_ace( ... )
set_dacl( ... ) // Discresionary ACL
set_sacl( ... ) // System ACL
free_sd( ... )

check_sd_access( &sd, desired_access, &user_info3, &override_acl )
check_sd_whatever( ... )
check_sd_audit( ... )
check_sd_alarm( ... )

What is gained is that nowhere ouside the read and write functions do
you need to know if you are working with a file system ACL/SD or a NT
ACL/SD. You don't need to know what system calls are defined and how
they are used. You will know what each bit means (without redefining a
large set of macros for each platform). Basically everything in samba
will be the same except for which read/write functions is used
depending on what system/file system you want to work with ACLs/SDs
on.

I'd also like to start asking what MAXIMUM_ALLOWED is supposed to
return in anything but the most simple ACL? Answer this example:
ACL
 ACE allows 0x7FFF
 ACE denies 0x4000
 ACE allows 0x8000
What access permission is a user allowed to which these three ACEs
apply? My understanding of the ACL: any of the 0x7FFF bits are allowd
if the 0x8000 bit isn't set. If it is set, any of the 0xBFFF bits are
allowed.

Finally, just for semantic correctness. A SD API in samba, regardless
of whether if it is exactly equal to NT or any other system, will be
an internal API, unless that system is also in samba. Morale: real NT
SDs do only exist on NT, we can have an equal, compatible or non
compatible API as long as we don't run on NT. I'm doing fully
compatible. Luke, you cannot avoid having an internal intermediate SD
API in samba if you don't run samba on a system that supply it for
you, and then you will still need to convert it before sending it to
the net (unless it's NT).

Best regards
  Michael Stockman
  pgmtekn-micke at algonet.se