[Freeipa-devel] containers

[John Dennis]

Simo Sorce wrote:
> On Fri, 2007-11-16 at 10:55 -0500, John Dennis wrote:
>> 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.

But they aren't. See get_user_by_uid(), it just searches for uid=XXX. 
Doesn't that have the potential to return any entry with a uid 
attribute? I realize you're going to say "but nothing else in the tree 
should ever have a uid attribute". That might be hard to enforce and if 
it's not the uid attribute it might be some other non-unique attribute 
that creates a problem, just don't get too hung up on uid as the example.

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

Containers are like name spaces, without them it's like programming with 
a lot of global variables.

> What kind of conflicts do you see for radius?

I'm not sure there is a specific problem yet, it just feels like a 
potential problem if you don't "namespace" things.

Here's where I first started to sense a problem. Radius profiles can be 
attached to user entries or they can live independently, in this case 
under the profiles container of the radius service. When the profile is 
attached to a user it's looked up by uid. What does it get looked up by 
when it's under the profiles container? There is a temptation to have it 
referenced by the same attribute but point the search at a different 
container. In this particular instance I think the correct solution is 
to have the profile referenced by 'cn' in the profiles container and 
make sure that any search will use a different attribute depending on 
which container it's in.

That's all well and good, but it requires a certain discipline, just 
like using global variables, to make sure you never introduce a 
conflict. As more and more data gets added it might be hard to enforce 
that discipline and gaurantee robustness.

The discipline also means certain attributes can never be used in other 
entries or you run the risk of a loosely specified search which starts 
at the root finding it.

Namespaces were introduced in part to solve 'programming discipline' 
problems and segment data, it seems to me containers are equivalent to 
namespaces with many of the same issues. If you're looking for some data 
look for it in its namespace, not in the union of all namespaces, e.g. 
start the search at the appropriate container, not the root.



-- 
John Dennis <jdennis at redhat.com>