mod_shared_roster_ldap ldap_rfilter mangled by ejabberd #246

Closed
bklang opened this Issue Jul 9, 2014 · 12 comments

Comments

Projects
None yet
6 participants

bklang commented Jul 9, 2014

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.

Member

zinid commented Jul 10, 2014

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.

zinid self-assigned this Jul 10, 2014

Contributor

benlangfeld commented Jul 10, 2014

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

Contributor

benlangfeld commented Jul 10, 2014

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

Member

zinid commented Jul 10, 2014

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

Member

zinid commented Jul 10, 2014

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

Contributor

benlangfeld commented Jul 10, 2014

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}]}]}}}
Contributor

benlangfeld commented Jul 10, 2014

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

Contributor

benlangfeld commented Jul 10, 2014

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.

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. :)

Contributor

benlangfeld commented Jul 10, 2014

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

Contributor

benlangfeld commented Jul 10, 2014

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

Contributor

benlangfeld commented Jul 10, 2014

This is fixed by #247.

badlop closed this Mar 4, 2015

@erszcz erszcz pushed a commit to erszcz/ejabberd that referenced this issue Nov 7, 2015

@fenek fenek Merge pull request #246 from pianiel/muc_multi_session
Allow multiple resources for the same JID in a MUC room
43bf023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment