Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

mod_shared_roster_ldap ldap_rfilter mangled by ejabberd #246

Open
bklang opened this Issue · 12 comments

5 participants

Ben Klang Evgeny Khramtsov Ben Langfeld Tim Stewart Mickaël Rémond
Ben Klang

Given this setting for ldap_rfilter:

{ldap_rfilter, "(&(objectClass=posixGroup)(!(ou:dn:=groups))(memberUid=%u))"},

The following LDAP filter is submitted to the LDAP server:

(&(&(objectClass=posixGroup)(!(ou:=groups)))(memberUid=bklang))

Note that the part of the filter that reads (ou:dn:=groups) becomes (ou:=groups), thus breaking the filter.

Evgeny Khramtsov
Collaborator

Indeed, my bad.
However, from the spec (RFC 4515) it is hard to understand which parts of text filter should be put into the corresponding ASN.1 LDAP structure. Any hint would be much appreciated.

Evgeny Khramtsov zinid self-assigned this
Ben Langfeld

@zinid Am I right in thinking that this modification is going on here?

Ben Langfeld

On further reading, it looks more likely to be here, specifically here.

Evgeny Khramtsov
Collaborator

@benlangfeld yep, there is a problem with grammar parser.

Evgeny Khramtsov
Collaborator

@benlangfeld so the problem is quite severe: it's a misfeature.

Ben Langfeld

Confirmation of the above suspicion:

7> eldap_filter:parse("(ou=groups)").
{ok,{equalityMatch,{'AttributeValueAssertion',"ou",
                                              "groups"}}}
8> eldap_filter:parse("(ou:dn:=groups)").
{error,{'EXIT',{undef,[{eldap,extensibleMatch,
                              ["groups",[{type,"ou"}]],
                              []},
                       {eldap_filter_yecc,yeccpars2_56,7,
                                          [{file,"eldap_filter_yecc.yrl"},{line,43}]},
                       {eldap_filter_yecc,yeccpars0,5,
                                          [{file,"/usr/local/Cellar/erlang/R16B03/lib/erlang/lib/parsetools-2.0.10/include/yeccpre.hrl"},
                                           {line,56}]},
                       {eldap_filter,parse,2,[{file,"eldap_filter.erl"},{line,84}]},
                       {erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,573}]},
                       {shell,exprs,7,[{file,"shell.erl"},{line,674}]},
                       {shell,eval_exprs,7,[{file,"shell.erl"},{line,629}]},
                       {shell,eval_loop,3,[{file,"shell.erl"},{line,614}]}]}}}
Ben Langfeld

Just dumping some more references, Section 4 of RFC2254 and this section of the parser grammar. Seem relevant.

Ben Langfeld

Note that RFC2254 has been obsoleted by RFC4515, which states:

(o:dn:=Ace Industry)
[The fourth example] denotes an equality match, except that DN components should be considered part of the entry when doing the match.

Tim Stewart

Which branch or commit of ejabberd is used in these experiments? I pulled the latest master (07501f8) and I'm getting different results. Specifically, eldap_filter:parse/1 wants a binary and (when I give it one) I get this result instead:

4> eldap_filter:parse(<<"(ou:dn:=groups)">>).
{ok,{extensibleMatch,
        {'MatchingRuleAssertion',asn1_NOVALUE,<<"ou">>,<<"groups">>,
            asn1_DEFAULT}}}

I'm not claiming this is correct, just different. :)

Ben Langfeld

This is the 2.1.x branch, @timclassic :)

Ben Langfeld

I have a candidate fix. I'm in the process of testing this with a real query.

Ben Langfeld

This is fixed by #247.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.