[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-devel] containers



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 redhat com>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]