On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <[email protected]>wrote:
> Alex Karasulu wrote: > >> Just some history. When we went from using JNDI interfaces in the core to >> using our own well defined interfaces many things were a mess including >> this >> area. At one point I revamped this area of the code cleaning up a lot of >> the configuration which was still trying to use Properties a la the old >> JNDI >> way. >> I remember paying close attention to allow search operations to occur >> without a previous bind on the RootDSE regardless of whether or not >> anonymous binds were enabled or not. This was done specifically to allow >> for client's to discover the various ways they could bind to the directory >> by reading the RootDSE's contents. >> >> I've always thought the RootDSE was something that should be world >> readable >> but I may be wrong now with better clarification in the latest RFC revamp. >> Plus life has been hard and I cannot say I've been on top of these >> matters >> as I should. >> >> It might be best to consolidate the behavior of anonymous access to the >> server into a single configuration parameter which is an enumerated type >> with the following values. Let's call it anonymousAccess: >> >> o ANY - anonymous access to ANY entry is allowed >> o ROOTDSE - anonymous access is only allowed on the RootDSE >> o NONE - anonymous access is NOT allowed on any entry >> >> All these modes are still subject to any ACI restrictions that may >> additionally be configured by administrators. This parameter only governs >> at a high level which operations the network protocol layer will allow to >> occur on entries. Of course the lower layers also need to adhere to this >> policy if for example calls are made directly to the core interfaces via >> embedded server configurations where the API is used. >> >> WDYT? >> >> > I think we can do a little bit simpler. > > What about having the current flag (allowAnonymousAccess) which when set to > false forbid any access to any entry *except* for rootDSE (ie anonymous > search on rootDSE is allowed), plus an ACIItem to control the rootDSE access > if really needed ? > > Doing so will not change a lot of things in the server, and will leverage > the ACI subsystem only if really necessary. > > Yeah I guess this is much easier to implement but I see one main issue that will come up when trying to implement this. All ACI are subentries that must subordinate to a administrative point in the administrative area. We really do not have a centrally rooted system with a physical RootDSE where the RootDSE itself can be an administrative point. So we cannot subordinate ACI subentries underneath it in the way we can with the root entries of partitions. I really wanted to fix this problem by making a special root partition which would allow the RootDSE to act like an administrative point and possibly also hold the system information with the configuration etc. However a few premises have to change in the design to allow this. Not major but it can be done. Then your means to implementing the solution would be trivial.
