[PATCH] sam backend parameter

[Simo Sorce]

On Thu, 2002-10-03 at 03:01, Andrew Bartlett wrote:
> Simo Sorce wrote:
> 
> > Plus I have some questions about the current sam interface:
> > 
> > - what is all the context thing needed for?
> 
> I don't like global variables, and this allows us to construct seperate
> contexts for operations like sam2sam, and testing, without fiddiling
> with global variables.

There's no problem in having global variables, provided they are used
correctly. Insisting to not use them in any case just as a preconcept is
as wrong as using them too much.

It is all a question on how and where you use them.

sam2sam operation does not need access checking and interface
virtualization, it is an administrative task only anyway, try to put
sam2sam above the sam interface instead of making it directly connect to
the backends is just a bad idea, it add complexity and potential
problems and gain nothing, imho.

And sam2 sam is the only case where it could be useful to have 2
backends loaded at the same time. So it is perfectly possible to make
it's own init function that load 2 backends into 2 local (to samedit)
variables, while still loading the sam backend into a global variable
used by the sam interface inside smbd.

> > - what is the handle thing needed for ?
> 
> Same as the SAM_ACCOUNT in pdb.  

If it's a SAM_ACCOUNT then call it with it's name.
Also I really to not like the private substructure.
We are all adult and vaccinated, and must trust each other ability to
code and use internal structures properly, trying to say: " I do not
trust other coders " is not a bright move imho, add unneeded complexity,
SAM_ACCOUNT structure directly will do so regardless if theres a thing
called private or not. Adding this layer only makes the interface a lot
more heavier and trickier, make code slower (adds a function call for
each parameter to be set into a structure) and the sam interface a lot
bigger.

Effort should be spent to educate other programmers to use the thing the
right way by writing documentation, not by setting artificial barriers.

> > - what is access desired meant to do ? Authorization is a different
> > thing then storage, a backend is a storage!
> 
> The SAM interface layer is the 'choke point'.  If we do not wan't nasty
> races, then we must reterive things like the security descriptor with
> the data it applies to.  This implies that the ACL checking code must
> resise either in the SAM backend, or the SAM interface.  If we export it
> above this layer, we *will* get places where we don't check it properly.

It must be in the Interface, putting it on the backend is the wrong move
for many reasons:
- code duplication, you have to implement the access checking into evry
backend.
- code review, authorization is a critical part of the security in
samba, if you have to double check every module to be sure it does
things the right way, you simply castrate the potentiality of a loadble
module interface, as you put too much responsibility on independent
module coders.
- consistency every change you need to make to the access checking code,
bust be made to any module and will make out of sync any modules not
under your control, increasing the module versioning nightmare.
- races may be easily solved supporting locks on the backend.

> > - why do we insist to have a thing called unix accounts? It just does
> > not make sense to me. We need "real" users/groups mapping instead
> > (opposed to created on the fly by winbind based accounts).
> 
> I'm not sure what you mean here - the current code doesn't even know
> about unix accounts.

They are present in pdb, and I remember at some point of the discussion
we had on IRC someone claimed that multiple modules were also a way to
solve the unix accounts problem like done in with pdb backends.

What Instead I think is that we should not threat unix accounts in any
special way, but instead we need to map them to normal users when they
are present, if a user do not have a local unix user then it will be
created in winbindd, otherwise the uid->SID mapping will be done so that
the user is mapped on a unix user.

All the mapping should consist ONLY of a SID->[u,g]id mapping imho, and
we should discourage using unix groups provided from /etc/group file and
use instead winbindd to provide them to the system, but still use them
from /etc/group if the administrator want to do so.

Simo.

-- 
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20021003/a0c069bb/attachment.bin