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