Bug 504383 - PCRE breaks SASL Mapping
PCRE breaks SASL Mapping
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
1.2.1
All Linux
high Severity high
: ---
: ---
Assigned To: Noriko Hosoi
Viktor Ashirov
:
: 507401 (view as bug list)
Depends On:
Blocks: 434914 389_1.2.1
  Show dependency treegraph
 
Reported: 2009-06-05 18:38 EDT by Rich Megginson
Modified: 2015-12-07 11:47 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 11:47:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
git patch file for sasl_map.c (1.85 KB, patch)
2009-06-23 17:15 EDT, Noriko Hosoi
no flags Details | Diff
git merge/push messages (418 bytes, text/plain)
2009-06-23 17:54 EDT, Noriko Hosoi
no flags Details

  None (edit)
Description Rich Megginson 2009-06-05 18:38:14 EDT
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.
Comment 1 Jenny Galipeau 2009-06-23 10:17:06 EDT
*** Bug 507401 has been marked as a duplicate of this bug. ***
Comment 2 Noriko Hosoi 2009-06-23 17:15:57 EDT
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.
Comment 3 Rich Megginson 2009-06-23 17:38:16 EDT
Ok.  If someone really does want to match a literal '(' or ')' they can use \\( or use a character class like [(].
Comment 4 Noriko Hosoi 2009-06-23 17:54:26 EDT
Created attachment 349158 [details]
git merge/push messages

Reviewed by Rich (Thank you!!)

Pushed to master.
Comment 5 Sankar Ramalingam 2009-09-20 06:56:21 EDT
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.
Comment 6 Noriko Hosoi 2009-09-21 12:01:31 EDT
(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).
Comment 7 Jenny Galipeau 2010-05-26 14:41:21 EDT
can you please add steps to reproduce? thanks!
Comment 8 Rich Megginson 2010-05-26 14:54:49 EDT
(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.
Comment 9 Jenny Galipeau 2010-05-26 15:29:46 EDT
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
Comment 10 Jenny Galipeau 2010-05-26 15:31:01 EDT
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@BOS.REDHAT.COM)

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Note You need to log in before you can comment on or make changes to this bug.