[Freeipa-devel] containers

Simo Sorce ssorce at redhat.com
Fri Nov 16 16:32:05 UTC 2007


On Fri, 2007-11-16 at 10:55 -0500, John Dennis wrote:
> From reading the code in funcs.py I think we might have 
> collision/ambiguity problem. The code seems a bit schizophrenic about 
> specifying the container in which to search. In many instances a search 
> will just start at the suffix and makes the assumption the attribute it 
> is searching for is unique, that is probably not a good assumption if 
> you have more than one container in the tree.
> 
> The add_{user,group}() methods take an optional container parameter but 
> the __is_{user,group}_unique() methods ignore it and just search from 
> the root. The same holds true for the get_XXX_by_XXX() methods.
> 
> If there is more than one container in the tree we'll end up with 
> inconsistent results. Will we ever have more than one container for 
> things? Yes. For instance radius wants to have containers under 
> services. I'm afraid some of the root based searches could end up 
> finding things there instead. Whether or not this is true for specific 
> pieces of radius data (I have not verified this due to bad searches) it 
> just seems like a lurking problem and potential source of bugs, 
> especially as more and more data gets added to the tree and hung off of 
> different container nodes.
> 
> Shouldn't the functions performing searches always specify the container 
> they are searching under?

As long as the correct objectClasses are searched for the current
behavior is correct.

If we find 2 users with the same uid for example we are in trouble
anyway as uid is used in client to name users, same for cn and objects
with posixGroup objectClass.

What kind of conflicts do you see for radius?

And please can you send a little schematics of what exactly you need and
why and how you would propose to add subtrees (and where) ?

Simo.

-- 
| Simo S Sorce |
| Sr.Soft.Eng. |
| Red Hat, Inc |
| New York, NY |




More information about the Freeipa-devel mailing list