directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: [jira] Created: (DIRSERVER-1383) There is a confusion between Anonymous access and Access to rootDSE
Date Tue, 21 Jul 2009 15:28:36 GMT
On Tue, Jul 21, 2009 at 11:24 AM, Emmanuel Lecharny <>wrote:

> Alex Karasulu wrote:
>> On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <
>> >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 ::
Apache Directory Server ::
Apache MINA ::

View raw message