directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@gmail.com>
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 <elecharny@apache.org>wrote:

> Alex Karasulu wrote:
>
>> On Tue, Jul 21, 2009 at 10:50 AM, Emmanuel Lecharny <elecharny@apache.org
>> >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

Mime
View raw message