Question related to undefined filters
Hi! recently, I was working on fixing a NPE in the server. Thtis was due to a wrong filter being sent, where a Substring filter was used for an attribute that does not have a SunstringMR (uniqueMmeber). The filter was like (uniqueMmeber=abc*). RFC 4511 is not absolutely clear about what to do in this case, or should I say, I'm not absolutely sure I understand what it says: A server MUST evaluate filters according to the three-valued logic of [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for a particular entry, then the attributes of that entry are returned as part of the Search result (subject to any applicable access control restrictions). If the filter evaluates to FALSE or Undefined, then the entry is ignored for the Search. A filter of the "and" choice is TRUE if all the filters in the SET OF evaluate to TRUE, FALSE if at least one filter is FALSE, and Undefined otherwise. A filter of the "or" choice is FALSE if all the filters in the SET OF evaluate to FALSE, TRUE if at least one filter is TRUE, and Undefined otherwise. A filter of the 'not' choice is TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and Undefined if it is Undefined. A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. Examples include: - An attribute description in an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter is not recognized by the server. - The attribute type does not define the appropriate matching rule. - A MatchingRuleId in the extensibleMatch is not recognized by the server or is not valid for the attribute type. - The type of filtering requested is not implemented. - The assertion value is invalid. For example, if a server did not recognize the attribute type shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12), and (shoeSize<=12) would each evaluate to Undefined. AFAICU, an entry having a uniqueMember attribute should simply noit be returned when the bad filter is used. I'm fine with this logic, assuming this is the correct one. Any remark or clarification ? Many thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSERVER-2362) ApacheDS 2.0.0-M17 references older log4j that has security vulnerabilities
[ https://issues.apache.org/jira/browse/DIRSERVER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474653#comment-17474653 ] Michael commented on DIRSERVER-2362: Yes, specific vulnerability includes Log4Shell, JNDI Lookup. According to this article, log4j1.x doesn't offer JNDI lookup but it does come with JMSAppender which can also be vulnerable for an attack. [https://www.slf4j.org/log4shell.html] Do you know if ApacheDS log4j1.2 use JMSAppender? or any other possible vulnerability? In addition, is there a plan for ApacheDS to move to newer log4j2 version that resolves these security vulnerabilities? > ApacheDS 2.0.0-M17 references older log4j that has security vulnerabilities > --- > > Key: DIRSERVER-2362 > URL: https://issues.apache.org/jira/browse/DIRSERVER-2362 > Project: Directory ApacheDS > Issue Type: Bug >Affects Versions: 2.0.0-M17 >Reporter: Michael >Priority: Major > > ApacheDS 2.0.0-M17 (apacheds-service-2.0.0-M17.jar) references older log4j > version that might have security vulnerabilities. > Does ApacheDS 2.0.0-M17 log4j reference have security vulnerabilities? > Is there a newer ApacheDS version that uses newer log4j2 that resolves the > security vulnerabilities? > > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[jira] [Commented] (DIRSTUDIO-1289) Can't connect to ldaps behind haproxy in M17
[
https://issues.apache.org/jira/browse/DIRSTUDIO-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17474929#comment-17474929
]
Sergey B. commented on DIRSTUDIO-1289:
--
Experience the same problem on Windows with version 2.0.0.v20210717-M17 and
java 17.0.1.
> Can't connect to ldaps behind haproxy in M17
>
>
> Key: DIRSTUDIO-1289
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1289
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
>Affects Versions: 2.0.0-M17
> Environment: OS: Linux, v.5.13.13-arch1-1, x86_64 / gtk 3.24.30
> Java version: 16.0.2
>Reporter: Josef Vybíhal
>Priority: Minor
> Labels: LDAPS, haproxy
> Fix For: 2.0.0-M16
>
>
> I have noticed, that I can not connect to ldaps server which is behind SSL
> terminated haproxy.
> The error seems to be timeout
> {code:java}
> Error while opening connectionError while opening connection -
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was
> found.org.apache.directory.studio.connection.core.io.StudioLdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.toStudioLdapException(DirectoryApiConnectionWrapper.java:1350)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$2(DirectoryApiConnectionWrapper.java:1342)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:483)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1261)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.doBind(DirectoryApiConnectionWrapper.java:488)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bind(DirectoryApiConnectionWrapper.java:323)
> at
> org.apache.directory.studio.connection.core.jobs.OpenConnectionsRunnable.run(OpenConnectionsRunnable.java:114)
> at
> org.apache.directory.studio.connection.core.jobs.StudioConnectionJob.run(StudioConnectionJob.java:109)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)Caused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found. at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1578)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.bindSimple(DirectoryApiConnectionWrapper.java:339)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$5(DirectoryApiConnectionWrapper.java:333)
> at
> org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$2.run(DirectoryApiConnectionWrapper.java:395)
> ... 6 moreCaused by:
> org.apache.directory.api.ldap.model.exception.LdapException:
> ERR_04170_TIMEOUT_OCCURED TimeOut occurred at
> org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1549)
> ... 9 more
> ERR_04169_RESPONSE_QUEUE_EMPTIED The response queue has been emptied, no
> response was found.{code}
> In the haproxy log, I can see the connection was made. The ldap servers in
> the backed are definitely responding properly (I can connect to them
> directly, and numerous applications are using this haproxy as ldap source,
> and it works perfectly fine).
> I suspect it is something in M17.
> When I downgraded to 2.0.0.v20210213-M16, it works fine - I can connect as
> expected. I have tried M17 with java-16-jdk and java-11-openjdk, no change.
> Is there anything I could investigate more and help discovering what the
> issue might be?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
Re: Question related to undefined filters
I understand it the same way as you, especially the next paragraph makes it clear that no error must be returned: Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, assertion values are invalid, or the assertion syntax is not supported. More details of filter processing are given in Clause 7.8 of [X.511]. TBH, as a user, I'd prefer to get a clear error when my filter is invalid (fail fast) than an empty result where I don't understand why. This doesn't follow the principle of least surprise... Kind regards, Stefan On 1/12/22 11:12, Emmanuel Lécharny wrote: Hi! recently, I was working on fixing a NPE in the server. Thtis was due to a wrong filter being sent, where a Substring filter was used for an attribute that does not have a SunstringMR (uniqueMmeber). The filter was like (uniqueMmeber=abc*). RFC 4511 is not absolutely clear about what to do in this case, or should I say, I'm not absolutely sure I understand what it says: A server MUST evaluate filters according to the three-valued logic of [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for a particular entry, then the attributes of that entry are returned as part of the Search result (subject to any applicable access control restrictions). If the filter evaluates to FALSE or Undefined, then the entry is ignored for the Search. A filter of the "and" choice is TRUE if all the filters in the SET OF evaluate to TRUE, FALSE if at least one filter is FALSE, and Undefined otherwise. A filter of the "or" choice is FALSE if all the filters in the SET OF evaluate to FALSE, TRUE if at least one filter is TRUE, and Undefined otherwise. A filter of the 'not' choice is TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and Undefined if it is Undefined. A filter item evaluates to Undefined when the server would not be able to determine whether the assertion value matches an entry. Examples include: - An attribute description in an equalityMatch, substrings, greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter is not recognized by the server. - The attribute type does not define the appropriate matching rule. - A MatchingRuleId in the extensibleMatch is not recognized by the server or is not valid for the attribute type. - The type of filtering requested is not implemented. - The assertion value is invalid. For example, if a server did not recognize the attribute type shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12), and (shoeSize<=12) would each evaluate to Undefined. AFAICU, an entry having a uniqueMember attribute should simply noit be returned when the bad filter is used. I'm fine with this logic, assuming this is the correct one. Any remark or clarification ? Many thanks ! - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Re: Question related to undefined filters
On 12/01/2022 21:52, Stefan Seelmann wrote: I understand it the same way as you, especially the next paragraph makes it clear that no error must be returned: Servers MUST NOT return errors if attribute descriptions or matching rule ids are not recognized, assertion values are invalid, or the assertion syntax is not supported. More details of filter processing are given in Clause 7.8 of [X.511]. TBH, as a user, I'd prefer to get a clear error when my filter is invalid (fail fast) than an empty result where I don't understand why. This doesn't follow the principle of least surprise... Indeed, thus my question... I will add some logs when an Undefined filter is found, so that at leats we have some trace... Thanks ! -- *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE T. +33 (0)4 89 97 36 50 P. +33 (0)6 08 33 32 61 emmanuel.lecha...@busit.com https://www.busit.com/ - To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
Compilation pb
Hi,
I'm fighting with some compilations issues most certainly due to a
change in java > 8 ByteBuffer. I had to change the LDAP API
AbstractContainer rewind method :
public void rewind()
{
int start = stream.position() - 1 - tlv.getLengthNbBytes();
( ( Buffer ) stream ).position( start );
}
when it was :
public void rewind()
{
int start = stream.position() - 1 - tlv.getLengthNbBytes();
stream.position( start );
}
otherwise the compiler complain that ByteBuffer.position(int) is not
available. There is some report about this issue:
https://github.com/eclipse/jetty.project/issues/3244
It seems that we have a mixed up of generated code in different versions
of some sort.
Although my env is set to use Java 8 only, I'm facing this issue this
morning when it was worki,ng yesterday
I'm wondering if anyone has any clue about it?
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
emmanuel.lecha...@busit.com https://www.busit.com/
-
To unsubscribe, e-mail: dev-unsubscr...@directory.apache.org
For additional commands, e-mail: dev-h...@directory.apache.org
