On Tue, Jul 21, 2009 at 11:24 AM, Emmanuel Lecharny <[email protected]>wrote:
> Alex Karasulu wrote: > >> 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. >> >> > > Right now, I would suggest we simply allow anonymous search on the rootDSE. > It's easy to do, we just have to fix the tests which are broken. The core > code won't be changed a lot (just a test in a method to remove). > > When we will have time (???), we can rethink the ACI stuff. > Sounds good to me. But let me note that there are many things including this issue that are awaiting a more wholesome solution regarding the way we handle partition and partition nesting. -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org
