directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [1.5.1] DIRSERVER-832 and how to fix it ...
Date Wed, 15 Aug 2007 16:22:04 GMT
Just thinking about this issue. Yeah it's a big one but I can knock this
out in less than a day.  I think what is more important is to get the big
picture of how many issues we have for 1.5.1 and which are going to
take a big effort.

If there are many hairy big work issues like this one then we can postpone
this and just get 1.5.1 out the door.  If there are not and we only have a
few
of these to deal with then I can make sure I knock this out in a day.

WDYT?

Alex

On 8/15/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
>
> Hi,
>
> we are trying to cut a 1.5.1 release soon, and we have a couple of
> serious issues on our road. DIRSERVER-832 is one of the most serious
> one, as it's impacting almost all the code
> (https://140.211.11.4/jira/browse/DIRSERVER-832).
>
> The main problem with this bug is that we need to deeply modify the
> server to eradicate this potential problem. Here is what we should
> check :
> - when comparing attributeTypes, we should do it using a case
> insensitive comparison (not a big deal !)
> - when comparing values, we *must* use the matching rules to be sure
> that the comparison is correctly working. This is where we hit the
> wall...
>
> For instance, just have a look at the isRemovable() method in the
> org.apache.directory.server.core.authz.support.RestrictedByFilter.java
> file. (apacheds-core sub-project). What we can find is such a code :
>
> ...
>                 for ( Iterator k = rb.iterator(); k.hasNext(); )
>                 {
>                     RestrictedByItem rbItem = ( RestrictedByItem ) k.next
> ();
>
>                     if ( attrId.equalsIgnoreCase( rbItem.getAttributeType()
> ) )
>                     {
>                         Attribute attr = entry.get( rbItem.getValuesIn()
> );
>
>                         if ( attr == null || !attr.contains( attrValue ) )
>                         {
>                             return true;
>                         }
>                     }
>                 }
> ...
>
> The last test is badly wrong : attr.contains( attrValue ) will just
> compare the value as is, without applying any normalization to the
> value. Another problem is that if ( attrId.equalsIgnoreCase(
> rbItem.getAttributeType() ) ) won't work if the ACI contains an OID
> and the RestrictedByItem contains a name...
>
> We have a couple of helper methods in an AttributeUtils class, like :
> public final static boolean containsValue( Attribute attr, Object
> compared, AttributeType type ),
> but this is only if one can access the registries to grab the
> AttributeType. Alas, those registries are not accessible everywhere in
> the code...
>
> So now, what next ? I would suggest as a quick fix to add an accessor
> to those registries which will be a singleton (I know, Pattern purists
> will axe me ...), because it's the fastest way to fix this problem,
> and I can't think about some other way (unless we add one more
> parameter to the initial method : an accessor to the registry. Yuk
> ...)
>
> thoughts ?
>
> (Remember, this is a Blocker !)
> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>

Mime
View raw message