OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/7673
Full headers

From: Russell.Mosemann@cune.edu
Subject: rwm and bad ACL evaluation
Compose comment
Download message
State:
0 replies:
11 followups: 1 2 3 4 5 6 7 8 9 10 11

Major security issue: yes  no

Notes:

Notification:


Date: Tue, 27 Aug 2013 18:12:37 +0000
From: Russell.Mosemann@cune.edu
To: openldap-its@OpenLDAP.org
Subject: rwm and bad ACL evaluation
Full_Name: Russell Mosemann
Version: 2.4.36
OS: Debian 6 and 7
URL: 
Submission from: (NULL) (192.160.64.50)


Including rwm directives causes ACL evaluation to be incorrectly performed. rwm
plays no role in rewriting any part of the incoming query or outgoing results.
Simply commenting the rwm lines without making any other configuration changes
permits the query to succeed. The query is coming from an authenticated entry
that is allowed to search the subtree.

# rwm configuration - Commenting the follow lines allows the query to succeed.

overlay             rwm
rwm-rewriteEngine   on
rwm-rewriteMap      slapd flt2dn "ldap:///ou=accounts,o=cune?dn?sub"
rwm-rewriteContext  bindDN
rwm-rewriteRule     "^(mail=[a-z0-9-]+\\.[a-z0-9-]+@cune\\.org),ou=People,o=cune$"
                    "${flt2dn((\&($1)(accountStatus=active)(userClass=stu)))}"
                    ":@I"

# There are only 4 ACLs.

# Allow authentication
access to dn.subtree="ou=accounts,o=cune" attrs=userPassword
  by self write
  by peername.ip=127.0.0.0%255.255.255.0 search
  by peername.ip=10.0.0.0%255.255.192.0 search
  by anonymous auth

# Allow reading of certain attributes.
access to dn.subtree="ou=accounts,o=cune"
  filter=(&(userClass=stu)(accountStatus=active))
  attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus
  by dn="qmailGID=306,ou=accounts,o=cune" read
  by peername.ip=127.0.0.0%255.255.255.0 read
  by peername.ip=10.0.0.0%255.255.192.0 read
  by * none

# Search access to the base is required to search children.
access to dn.base="ou=accounts,o=cune"
  by dn="qmailGID=306,ou=accounts,o=cune" search
  by peername.ip=127.0.0.0%255.255.255.0 read
  by peername.ip=10.0.0.0%255.255.192.0 read
  by * none

# No access to other parts.
access to dn.subtree="o=cune"
  by dn="qmailGID=306,ou=accounts,o=cune" none
  by peername.ip=127.0.0.0%255.255.255.0 read
  by peername.ip=10.0.0.0%255.255.192.0 read
  by * none


The query is from the authenticated entry "qmailGID=306,ou=accounts,o=cune"
searching the base "ou=accounts,o=cune" with the filter "(uid=Test.Entry)". This
is the debugging output when the rwm lines above are commented. The query
succeeds.

521cdb75 => send_search_entry: conn 1001 dn="qmailUID=2,ou=accounts,o=cune"
521cdb75 => access_allowed: read access to "qmailUID=2,ou=accounts,o=cune"
"entry" requested
521cdb75 => dn: [1] ou=accounts,o=cune
521cdb75 => acl_get: [1] matched
521cdb75 => dn: [2] ou=accounts,o=cune
521cdb75 => acl_get: [2] matched
521cdb75 => test_filter
521cdb75     AND
521cdb75 => test_filter_and
521cdb75 => test_filter
521cdb75     EQUALITY
521cdb75 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune"
"userClass" requested
521cdb75 <= test_filter 6
521cdb75 => test_filter
521cdb75     EQUALITY
521cdb75 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune"
"accountStatus" requested
521cdb75 <= test_filter 6
521cdb75 <= test_filter_and 6
521cdb75 <= test_filter 6
521cdb75 => acl_get: [2] attr entry
521cdb75 => acl_mask: access to entry "qmailUID=2,ou=accounts,o=cune", attr
"entry" requested
521cdb75 => acl_mask: to all values by "qmailGID=306,ou=accounts,o=cune",
(=0)
521cdb75 <= check a_dn_pat: qmailGID=306,ou=accounts,o=cune
521cdb75 <= acl_mask: [1] applying read(=rscxd) (stop)
521cdb75 <= acl_mask: [1] mask: read(=rscxd)
521cdb75 => slap_access_allowed: read access granted by read(=rscxd)
521cdb75 => access_allowed: read access granted by read(=rscxd)
ber_flush2: 40 bytes to sd 22
  0000:  30 26 02 01 02 64 21 04  1d 71 6d 61 69 6c 55 49  
0&...d!..qmailUI
  0010:  44 3d 32 2c 6f 75 3d 61  63 63 6f 75 6e 74 73 2c   D=2,ou=accounts,
  0020:  6f 3d 63 75 6e 65 30 00                            o=cune0.
ldap_write: want=40, written=40
  0000:  30 26 02 01 02 64 21 04  1d 71 6d 61 69 6c 55 49  
0&...d!..qmailUI
  0010:  44 3d 32 2c 6f 75 3d 61  63 63 6f 75 6e 74 73 2c   D=2,ou=accounts,
  0020:  6f 3d 63 75 6e 65 30 00                            o=cune0.
521cdb75 <= send_search_entry: conn 1001 exit.
521cdb75 send_ldap_result: conn=1001 op=1 p=3
521cdb75 send_ldap_result: err=0 matched="" text=""
521cdb75 send_ldap_response: msgid=2 tag=101 err=0


This is the debugging output after uncommenting the rwm lines and making no
other configuration changes. Search access allowed in the second ACL is not
found, and it proceeds to the fourth ACL where all access is denied.

521cdd96 => send_search_entry: conn 1004 dn="qmailUID=2,ou=accounts,o=cune"
521cdd96 => access_allowed: read access to "qmailUID=2,ou=accounts,o=cune"
"entry" requested
521cdd96 => dn: [1] ou=accounts,o=cune
521cdd96 => acl_get: [1] matched
521cdd96 => dn: [2] ou=accounts,o=cune
521cdd96 => acl_get: [2] matched
521cdd96 => test_filter
521cdd96     AND
521cdd96 => test_filter_and
521cdd96 => tes

Message of length 6486 truncated

Followup 1

Download message
From: "Mosemann, Russell" <Russell.Mosemann@cune.edu>
To: "'openldap-its@OpenLDAP.org'" <openldap-its@OpenLDAP.org>
Subject: RE: (ITS#7673) rwm and bad ACL evaluation
Date: Sat, 31 Aug 2013 18:17:53 +0000
Further testing confirms that the filter for the ACL is not being applied
correctly when rwm is used. Turning the rewriteEngine off has no effect. All
lines referring to rwm must be commented.

Interestingly, performing the query without specifying any attribute succeeds.
All allowed attributes are returned.

ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \
 -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)"

# extended LDIF
#
# LDAPv3
# base <ou=accounts,o=cune> with scope subtree
# filter: (uid=Test.Entry)
# requesting: ALL
#

# 2, accounts, cune
dn: qmailUID=2,ou=accounts,o=cune
objectClass: pilotPerson
objectClass: qmailUser
objectClass: PureFTPdUser
cn: Test Entry
sn: Entry
uid: Test.Entry
accountStatus: active
mail: test.entry@cune.org
userClass: stu

# search result
search: 2
result: 0 Success


Specifying an allowed attribute or no attributes (1.1) causes the query to fail.
For example,

ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \
 -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" cn

ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \
 -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" 1.1

# extended LDIF
#
# LDAPv3
# base <ou=accounts,o=cune> with scope subtree
# filter: (uid=Test.Entry)
# requesting: cn
#

# search result
search: 2
result: 32 No such object

# numResponses: 1


Removing the filter from the ACL allows the query to succeed.

access to dn.subtree="ou=accounts,o=cune"
  attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus
  by dn="qmailGID=306,ou=accounts,o=cune" read
  by peername.ip=127.0.0.0%255.255.255.0 read
  by peername.ip=10.0.0.0%255.255.192.0 read
  by * none


In summary, slapd is unable to apply the filter for an ACL correctly when rwm is
being used and an attribute (or no attributes) is specified with the query.



Followup 2

Download message
Date: Mon, 02 Sep 2013 15:37:32 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Russell.Mosemann@cune.edu, openldap-its@openldap.org
Subject: Re: (ITS#7673) rwm and bad ACL evaluation
This is a cryptographically signed message in MIME format.

--------------ms030200060406090105050307
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Russell.Mosemann@cune.edu wrote:
> Further testing confirms that the filter for the ACL is not being appli=
ed
> correctly when rwm is used. Turning the rewriteEngine off has no effect=
=2E
> All lines referring to rwm must be commented.
>=20
> Interestingly, performing the query without specifying any attribute
> succeeds. All allowed attributes are returned.

Hmm, maybe it's related to this:

http://www.openldap.org/its/index.cgi?findid=3D7495

Ciao, Michael.


--------------ms030200060406090105050307
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTAyMTMzNzMyWjAj
BgkqhkiG9w0BCQQxFgQUSUWFlNi+P3gVhEYcXVvCWpgF+p0wbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAHz5RR3K9GzJnvCkk+VEaz3FbSTprmvi/
Ey1b74sXSMNwTx85VZ12vvZZquUFwFxXckqtNoqlHQfggDf224UjQB0Fx8NTzdwKuMDJAjBI
+/VGV0EP7EXkhHXoPjYAhiWU2QnX4/bWLMwIaXYhT2ANJL9dV03WU6Y2UoC6Sh+xdKEQOCA4
kjQ54Zi5e09/KuWl+3eIQivGzIi+5zbukV6VHvumpQd5IL4s1F8VTHpHgmMQiDLPK2xv5+Uc
DuwnggSmLjskrUwg7uQtJARk3Cx6k9+SM0dB0c5Edrv8kDoDpFEanS5zvtRVP13/415dJJcP
MH5Bv8s+9RzDAKF6D4vcAAAAAAAAAA==
--------------ms030200060406090105050307--



Followup 3

Download message
From: "Mosemann, Russell" <Russell.Mosemann@cune.edu>
To: =?iso-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>,
        "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: RE: (ITS#7673) rwm and bad ACL evaluation
Date: Mon, 2 Sep 2013 19:56:23 +0000
> Hmm, maybe it's related to this:
> http://www.openldap.org/its/index.cgi?findid=7495

extra_attrs is a great suggestion. Unfortunately, it doesn't work. If I execute
the query and specify an attribute, it returns nothing. If I execute the query
and do not specify an attribute, slapd dies, which is what you reported.

--
Russell Mosemann, Ph.D.
Professor of Computer Science



Followup 4

Download message
From: "Mosemann, Russell" <Russell.Mosemann@cune.edu>
To: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: (ITS#7673)
Date: Wed, 4 Sep 2013 20:21:41 +0000
--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The lookup succeeds, and the returned entry is run through the searchEntryD=
N context. It appears that somewhere in or around there all of the attribut=
es are removed except for the requested attributes. That means the ACL filt=
er will fail, if the filter attributes are not requested in the query. If t=
he requested attributes include the filter attributes, the query succeeds, =
but the result only returns the dn without any other attributes.

If no attributes are requested, all allowed attributes are returned.

The man page indicates that searchEntryDN should not be applied, because it=
 is not defined, and there is no default.


--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Times New Roman","serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;">The lookup succeeds, and
the returne=
d entry is run through the searchEntryDN context. It appears that somewhere=
 in or around there all of the attributes are removed except
 for the requested attributes. That means the ACL filter will fail, if the =
filter attributes are not requested in the query. If the requested attribut=
es include the filter attributes, the query succeeds, but the result only r=
eturns the dn without any other
 attributes.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;">If no attributes are
requested, all =
allowed attributes are returned.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;">The man page indicates
that searchEn=
tryDN should not be applied, because it is not defined, and there is no def=
ault.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
</div>
</body>
</html>

--_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_--



Followup 5

Download message
Date: Wed, 4 Sep 2013 22:46:28 +0200
From: Pierangelo Masarati <pierangelo.masarati@polimi.it>
To: <Russell.Mosemann@cune.edu>
CC: <openldap-its@openldap.org>
Subject: Re: (ITS#7673)
On 09/04/2013 10:22 PM, Russell.Mosemann@cune.edu wrote:
> --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> The lookup succeeds, and the returned entry is run through the
searchEntryD=
> N context. It appears that somewhere in or around there all of the
attribut=
> es are removed except for the requested attributes. That means the ACL
filt=
> er will fail, if the filter attributes are not requested in the query. If
t=
> he requested attributes include the filter attributes, the query succeeds,
=
> but the result only returns the dn without any other attributes.
>
> If no attributes are requested, all allowed attributes are returned.
>
> The man page indicates that searchEntryDN should not be applied, because
it=
>   is not defined, and there is no default.

Try rwm-drop-unrequested-attrs no (slapo-rwm(5)).

p.

>
>
> --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <html xmlns:v=3D"urn:schemas-microsoft-com:vml"
xmlns:o=3D"urn:schemas-micr=
> osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word"
=
> xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns=3D"http:=
> //www.w3.org/TR/REC-html40">
> <head>
> <meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3Dus-ascii"=
>>
> <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered
medium)">
> <style><!--
> /* Font Definitions */
> @font-face
> 	{font-family:"Cambria Math";
> 	panose-1:2 4 5 3 5 4 6 3 2 4;}
> @font-face
> 	{font-family:Calibri;
> 	panose-1:2 15 5 2 2 2 4 3 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	font-size:11.0pt;
> 	font-family:"Calibri","sans-serif";}
> a:link, span.MsoHyperlink
> 	{mso-style-priority:99;
> 	color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{mso-style-priority:99;
> 	color:purple;
> 	text-decoration:underline;}
> span.EmailStyle17
> 	{mso-style-type:personal-compose;
> 	font-family:"Times New Roman","serif";
> 	color:windowtext;}
> .MsoChpDefault
> 	{mso-style-type:export-only;
> 	font-family:"Calibri","sans-serif";}
> @page WordSection1
> 	{size:8.5in 11.0in;
> 	margin:1.0in 1.0in 1.0in 1.0in;}
> div.WordSection1
> 	{page:WordSection1;}
> --></style><!--[if gte mso 9]><xml>
> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
> </xml><![endif]--><!--[if gte mso 9]><xml>
> <o:shapelayout v:ext=3D"edit">
> <o:idmap v:ext=3D"edit" data=3D"1" />
> </o:shapelayout></xml><![endif]-->
> </head>
> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
> <div class=3D"WordSection1">
> <p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
> mes New Roman&quot;,&quot;serif&quot;">The lookup succeeds,
and the returne=
> d entry is run through the searchEntryDN context. It appears that
somewhere=
>   in or around there all of the attributes are removed except
>   for the requested attributes. That means the ACL filter will fail, if the
=
> filter attributes are not requested in the query. If the requested
attribut=
> es include the filter attributes, the query succeeds, but the result only
r=
> eturns the dn without any other
>   attributes.<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
> mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
> <p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
> mes New Roman&quot;,&quot;serif&quot;">If no attributes are
requested, all =
> allowed attributes are
returned.<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
> mes New Roman&quot;,&quot;serif&quot;"><o:p>&nbsp;</o:p></span></p>
> <p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
> mes New Roman&quot;,&quot;serif&quot;">The man page
indicates that searchEn=
> tryDN should not be applied, because it is not defined, and there is no
def=
> ault.<o:p></o:p></span></p>
> <p class=3D"MsoNormal"><span
style=3D"font-size:12.0pt;font-family:&quot;Ti=
> mes New Roman&quot;,&quot;serif&q

Message of length 5342 truncated


Followup 6

Download message
From: "Mosemann, Russell" <Russell.Mosemann@cune.edu>
To: Pierangelo Masarati <pierangelo.masarati@polimi.it>
CC: "openldap-its@openldap.org" <openldap-its@openldap.org>
Subject: RE: (ITS#7673)
Date: Wed, 4 Sep 2013 21:48:03 +0000
Pierangelo Masarati wrote:
> Try rwm-drop-unrequested-attrs no (slapo-rwm(5)).

That had my hopes up. I didn't think any of those settings applied, because
nothing about the query or the results is being rewritten or mapped. In effect,
rwm should not be doing anything at all. Everything should pass through the
overlay.

I set rwm-drop-unrequested-attrs to no, and it made things worse. If I include
the filter attributes in the query, nothing is returned, now. If no attributes
are specified, all of the allowed attributes are returned, as before.

--
Russell Mosemann, Ph.D.
Professor of Computer Science



Followup 7

Download message
From: "Mosemann, Russell" <Russell.Mosemann@cune.edu>
To: "openldap-its@OpenLDAP.org" <openldap-its@OpenLDAP.org>
Subject: RE: (ITS#7673) rwm and bad ACL evaluation
Date: Fri, 14 Mar 2014 22:53:25 +0000
I'm still looking for a resolution to the issue of the rewrite module
interfering with a search that does not use the rewrite module. The behavior has
not changed in the intervening updates. We are running 2.4.39, and simply
referencing rwm

overlay   rwm

returns no search results at all, if an attribute is specified for the search.
Specifying no attributes returns all of the allowed attributes. Commenting the
line above permits the specified attribute to be returned, as expected.

The rewrite module should have no interaction with the search whatsoever, since
no rewrite has been specified. Instead, it appears that the rwm intercepts the
returned results and somehow "loses" all of the attributes when the search
specifies a specific attribute. When no attribute is specified in the search,
rwm quietly stays out of the way and lets all of the returned attributes proceed
to the frontend.

--
Russell Mosemann, Ph.D.
Professor of Computer Science



Followup 8

Download message
Date: Sat, 15 Mar 2014 10:12:18 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: Russell.Mosemann@cune.edu, openldap-its@openldap.org
Subject: Re: (ITS#7673) rwm and bad ACL evaluation
This is a cryptographically signed message in MIME format.

--------------ms000109040804090309020609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Russell.Mosemann@cune.edu wrote:
> simply referencing rwm
>=20
> overlay   rwm
>=20
> returns no search results at all, if an attribute is specified for the
> search. Specifying no attributes returns all of the allowed attributes.=

> Commenting the line above permits the specified attribute to be returne=
d,
> as expected.

Did you already try with this?

rwm-drop-unrequested-attrs no

Ciao, Michael.


--------------ms000109040804090309020609
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzE1MDkxMjE4WjAj
BgkqhkiG9w0BCQQxFgQUrABzEjElf3V/cUntQuLyr7sa6GcwbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAv0di+TXxwjmc85Xw+S9qBwQag6dOQupE
IkAwHTdBFaFAYayl0ohH4+WQk2G7lxxyy1Mr1dmva4ziV9Q0qhN7Oo7NMBMenK8WfcFJGlEs
+DrZoe4ZXws9BwArgzny5zZzJBaWod0nFaJ30Jj5A0S0GyiKAiOt2rzuFNIoEqiy9aSa/rqF
APQR7P3ocuY9yZsHi9Sr5vNQrQA9E1qk/iERvL2YTA0QAWSeNoD0YWY7qr5QoSQofwhmkGYf
UuCgmgjEPtztIVXrmxfx6FAx+/rr2ynYfMGwy3oLd9AhIC937NYoMxsBVsc7Tf7damWDanjH
rrcuNYm9zXayrPcANmjgHAAAAAAAAA==
--------------ms000109040804090309020609--



Followup 9

Download message
From: "Mosemann, Russell" <Russell.Mosemann@cune.edu>
To: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= <michael@stroeder.com>,
        "'openldap-its@openldap.org'" <openldap-its@openldap.org>
Subject: RE: (ITS#7673) rwm and bad ACL evaluation
Date: Sat, 15 Mar 2014 09:22:10 +0000
> Did you already try with this?
> 
> rwm-drop-unrequested-attrs no

If you look through the messages
(http://www.openldap.org/its/index.cgi?findid=7673), you will see that the same
suggestion was made by Pierangelo Masarati 6 months ago in followup 5. My
response in followup 6 was that it doesn't work. A quick test indicates that it
still does not work in 2.4.39.

--
Russell Mosemann, Ph.D.
Professor of Computer Science



Followup 10

Download message
Date: Sat, 15 Mar 2014 12:00:02 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: "Mosemann, Russell" <Russell.Mosemann@cune.edu>,
        "'openldap-its@openldap.org'" <openldap-its@openldap.org>
Subject: Re: (ITS#7673) rwm and bad ACL evaluation
This is a cryptographically signed message in MIME format.

--------------ms020400000305090906010704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Mosemann, Russell wrote:
>> Did you already try with this?
>>
>> rwm-drop-unrequested-attrs no
>=20
> If you look through the messages
> (http://www.openldap.org/its/index.cgi?findid=3D7673), you will see tha=
t the
> same suggestion was made by Pierangelo Masarati 6 months ago in followu=
p 5.
> My response in followup 6 was that it doesn't work. A quick test indica=
tes
> that it still does not work in 2.4.39.

I had a similar issue myself before:

http://www.openldap.org/its/index.cgi?findid=3D7495

Using extra_attrs as suggested by Hallvard gave seg fault as result.
Did not investigate it further though.

Using slapo-rwm is a pain. One will hit many seg faults.

Ciao, Michael.


--------------ms020400000305090906010704
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzE1MTEwMDAyWjAj
BgkqhkiG9w0BCQQxFgQUUSa2ArlMv5dRmzJlQRq5PcrRHkUwbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAvyDf1DHX6lO5GY/rJUE8fG+SMoafXeCK
H7gMAa2TDdkjvgjPDrfVSXHu+c0SGwayuluYm+A1NLPrJ0yuDD056fBFEBle/2mf6iD/AUC4
WqoLNLNtNAXomiyHoztxopV83jzbbA4xCHMvPr9PRtbtrr+uTmZGjOcxuEBj+0K+nUM4xFAU
OFWve6ySjrFpGj/7JfTkgMq2hqlkmLn6v9VgqqldkY5lEEKDbS3pFPyi+cTpB8EGh5uANGv9
q2ga1fkbkSBrMHEntQdvdT/puvVPZPJxgtL7ooTIXvmCQVMGnUEtOylUgYpCpCUHq3LXJ7dE
DM2tyDJ3+1IRihV81j/h0AAAAAAAAA==
--------------ms020400000305090906010704--



Followup 11

Download message
Date: Sat, 15 Mar 2014 05:15:52 -0700
From: Howard Chu <hyc@symas.com>
To: openldap-its@openldap.org
Subject: Re: (ITS#7673) rwm and bad ACL evaluation
michael@stroeder.com wrote:
> This is a cryptographically signed message in MIME format.

Is it really necessary to sign your emails to the ITS? The PKCS7 signature is 
longer than the message text.

> --------------ms020400000305090906010704
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> Mosemann, Russell wrote:
>>> Did you already try with this?
>>>
>>> rwm-drop-unrequested-attrs no
>> =20
>> If you look through the messages
>> (http://www.openldap.org/its/index.cgi?findid=3D7673), you will see
tha=
> t the
>> same suggestion was made by Pierangelo Masarati 6 months ago in
followu=
> p 5.
>> My response in followup 6 was that it doesn't work. A quick test
indica=
> tes
>> that it still does not work in 2.4.39.
>
> I had a similar issue myself before:
>
> http://www.openldap.org/its/index.cgi?findid=3D7495
>
> Using extra_attrs as suggested by Hallvard gave seg fault as result.
> Did not investigate it further though.
>
> Using slapo-rwm is a pain. One will hit many seg faults.

There are quite a few open bug reports against slapo-rwm. Patches welcome.
>
> Ciao, Michael.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org