Red Hat Bugzilla – Bug 504383
PCRE breaks SASL Mapping
Last modified: 2015-12-07 11:47:07 EST
The old regex code used \( \) to indicate grouping for use with \& and \1, \2, etc. PCRE uses () instead. When you upgrade to a directory server that uses PCRE, the sasl mapping code will look for literal '(' and ')' in the pattern and will fail. I'm not sure what the best way to handle this is.
1) When reading the sasl mapping config, we could just convert \( and \) to ( and ), and write the fixes back out to the config. That is probably the easiest way to handle upgrades.
2) Have setup -u go in and fix all of the configs.
1) is probably simpler, but might cause confusion if someone really did have a ( in a pattern, and really did want to match a literal '(' character.
*** Bug 507401 has been marked as a duplicate of this bug. ***
Created attachment 349151 [details]
git patch file for sasl_map.c
Fix Description: unescape parenthesis in the regular expression.
E.g., ^u:\(.*\) ==> ^u:(.*)
This unescape is necessary for the new regex code using PCRE
to keep the backward compatibility.
Ok. If someone really does want to match a literal '(' or ')' they can use \\( or use a character class like [(].
Created attachment 349158 [details]
git merge/push messages
Reviewed by Rich (Thank you!!)
Pushed to master.
I have checked the dse.ldif with the latest builds of 389-Directory server. Looks like the same old fashioned regular expressions with back slash(\) present in the sasl maps.
(In reply to comment #5)
> I have checked the dse.ldif with the latest builds of 389-Directory server.
> Looks like the same old fashioned regular expressions with back slash(\)
> present in the sasl maps.
Yes, the server should support the "old fashioned regular expressions", as well. Internally, it converts it to the PCRE format. That's the change made in the patch: Created an attachment (id=349151).
can you please add steps to reproduce? thanks!
(In reply to comment #7)
> can you please add steps to reproduce? thanks!
I don't think the bug was ever in a released server. I suppose you could just verify that the sasl maps with ( and ) in them do the correct matching, and that if you specify a sasl map with a [(] you can match a literal '(' string.
fix verified - Fedora 12
Successfully administration on ipa server (see duplicate bug for verification steps)
[root@dhcp-100-3-67 ~]# ipa-finduser admin
Home Directory: /home/admin
Login Shell: /bin/bash
Last Name: Administrator
IPA sasl maps:
ldapsearch -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=mapping,cn=sasl,cn=config"
# extended LDIF
# base <cn=mapping,cn=sasl,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# mapping, sasl, config
# Full Principal, mapping, sasl, config
dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config
cn: Full Principal
# Name Only, mapping, sasl, config
dn: cn=Name Only,cn=mapping,cn=sasl,cn=config
cn: Name Only
# search result
result: 0 Success
# numResponses: 4
# numEntries: 3