Bug 504383 - PCRE breaks SASL Mapping
Summary: PCRE breaks SASL Mapping
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.2.1
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
: 507401 (view as bug list)
Depends On:
Blocks: 434914 389_1.2.1
TreeView+ depends on / blocked
 
Reported: 2009-06-05 22:38 UTC by Rich Megginson
Modified: 2015-12-07 16:47 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:47:07 UTC


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

Description Rich Megginson 2009-06-05 22:38:14 UTC
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 14:17:06 UTC
*** Bug 507401 has been marked as a duplicate of this bug. ***

Comment 2 Noriko Hosoi 2009-06-23 21:15:57 UTC
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 21:38:16 UTC
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 21:54:26 UTC
Created attachment 349158 [details]
git merge/push messages

Reviewed by Rich (Thank you!!)

Pushed to master.

Comment 5 Sankar Ramalingam 2009-09-20 10:56:21 UTC
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 16:01:31 UTC
(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 18:41:21 UTC
can you please add steps to reproduce? thanks!

Comment 8 Rich Megginson 2010-05-26 18:54:49 UTC
(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 19:29:46 UTC
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 19:31:01 UTC
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.