[Freeipa-devel] containers

[Simo Sorce]

On Fri, 2007-11-16 at 13:00 -0500, John Dennis wrote:
> 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".

No I am going to say this is a bug, we should *always* search with the
right objectclass in the filter.

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

NO the bug is in not searching with the objectclass, for some reason
that slipped in that way, it's a bug.

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

Yes tell it to the nsswitch guys. For some things unfortunately our
world is still flat, we have to live with that.

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

We don't do namespace for anything user or group, simply because
nsswitch can't understand that. For anything else we can.

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

No, as long as the othe radius stuff does not contain posixAccount you
can use uid, an alternative solution is to use an attirbute unique to
radius. Searching gon different attribute based on the container, simply
put, is wrong on premises.


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

That's not good. Discipline in LDAP is based on objectClasses not on
tree structure. Anything that rely on the tree structure for generic
searches is often just bad architecture.

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

ObjectClasses, they are there exactly for that reason, filter what you
need from what you need not.

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

Ok you just got it wrong, in this context namespaces == objectClasses in
LDAP, the tree is not.

Simo.

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