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 File: ldap/servers/slapd/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 version: 389-ds-base-1.2.5-1.fc12.i686 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 Login: admin
additional information: IPA sasl maps: ldapsearch -x -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=mapping,cn=sasl,cn=config" # extended LDIF # # LDAPv3 # base <cn=mapping,cn=sasl,cn=config> with scope subtree # filter: (objectclass=*) # requesting: ALL # # mapping, sasl, config dn: cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsContainer cn: mapping # Full Principal, mapping, sasl, config dn: cn=Full Principal,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping nsSaslMapRegexString: \(.*\)@\(.*\) cn: Full Principal nsSaslMapBaseDNTemplate: dc=bos,dc=redhat,dc=com nsSaslMapFilterTemplate: (krbPrincipalName=\1@\2) # Name Only, mapping, sasl, config dn: cn=Name Only,cn=mapping,cn=sasl,cn=config objectClass: top objectClass: nsSaslMapping nsSaslMapRegexString: \(.*\) cn: Name Only nsSaslMapBaseDNTemplate: dc=bos,dc=redhat,dc=com nsSaslMapFilterTemplate: (krbPrincipalName=\1.COM) # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3