[PATCH] sam backend parameter

[Simo Sorce]

On Thu, 2002-10-03 at 12:34, Andrew Bartlett wrote:
> Simo Sorce wrote:
> > It is all a question on how and where you use them.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Except that global variables are particularly nasty in C - we don't have
> an autoprototyper on them, and we cannot ensure that they are correctly
> declared in all modules.  Also, we cannot validate the input into any
> such variables, or assume auto-initialisation.  The methods employed in
> the pdb and sam provide this.

> Honestly, it is a matter of taste.  I like the way that pdb (and now the
> SAM code) has been constructed, and the distinct lack of 'special
> cases'.  If pdbedit becomes a special case, then it is more likely to
> break.  If the rest of Samba has to use that code path, then accidents
> are less likely to happen.

pdbedit is not a special case, it only uses the backend interface and
not the sam interface, they will be both quite consistent!
No better the backend interface should be even more solid and stable
then sam interface as it have to deal with potentially external modules,
so i really do not see pdb/sam/gums/**edit to break so easily.


|         smbd        |
-----------------------
           |
-----------------------
|    sam interface    |
-----------------------
           |               ----
           |--------------|  pdbedit
           |               ----
-----------------------
|       backend       |
-----------------------

> > Effort should be spent to educate other programmers to use the thing the
> > right way by writing documentation, not by setting artificial barriers.
> 
> Here we disagree.  I take a different approach, were I prefer to make it
> harder to make mistakes.  

Harder to make mistake is good only when it does not imply harder to
code. I abide to the "Keep it Simple Stuipd!" religion :-)

> The use of 'set' routines has also allowed us to (with minimal changes
> to the interface) track 'default' values for many parameters - avoiding
> the storage of extra (fixed) values in LDAP.  I intend to expand this to
> every attribute for the new SAM.

The set routines may stay at the sam interface level, nobody prohibits
you to use them and they are certainly appealing in some situation, even
if I do not like them much and would prefer do be able to change a
structure directly if I need to do it (again I have to remember we are
using C not Java, and an object oriented way to do things is not always
a good thing imho).

Also I think it is bad you do not put extra values in LDAP, what happen
if you discover you need to support that to provide some functionality?
A re you going to change the LDAP schema between minor releases?

> Furthermore, we use the get/set routines to allow the users of the
> passdb interface to get feedback on the ability to get/set *individual*
> elements on the SAM handle, rather than the lot.

ability to set/get individual values ?
What do you exactly mean ?

> I advocate strong interfaces, because I feel it assists in modular
> programming.  By using the get/set routines, I can ensure that data is
> correctly 'const', for example.  Finally, it allows us to strdup() all
> assigned strings, and ensure they are not accidentally assigned stack
> pointers, while avoiding memory leaks.
> 
> On a project as large as Samba, I prefer all the help I can get in
> ensuring code quality.

You will get more quality documenting it then making barriers into it
imho.
I'm not saying we do not need clean interfaces, but that we should just
not push too much.

> > 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.
> 
> We cannot assume locks in the backend.  The interface is not designed in
> isolation - we have to work with the fact that LDAP *will* be a primary
> backend, and does not support this kind of locking.  I prefer to create
> a solution that does not impose additional constraints on this.

We can of course. There are many way to simulate locks even for ldap, as
it is clear that people should not be able to change user values if not
going through samba. Reading is not a problem, we only need lock on
write.

> Your points are very valid, and I have proposed a solution in the my
> reply to Jerry's mail.  That is, the backend can do it's own ACL checks
> if it likes, but it passes the security descriptor to the interface,
> where the 'real' check is performed.

No, checks should be done by the sam interface only, the backends should
be a storage only, that would ease a lot the backend code and avoid lot
of problems, see again the point above in my message about why to do so.

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

May be there is a chance to come to agreement then :-)

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/6ce9b06e/attachment.bin