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 => test_filter 521cdd96 EQUALITY 521cdd96 => access_allowed: search access to "qmailUID=2,ou=accounts,o=cune" "userClass" requested 521cdd96 <= test_filter 5 521cdd96 <= test_filter_and 5 521cdd96 <= test_filter 5 521cdd96 => dn: [3] ou=accounts,o=cune 521cdd96 => dn: [4] o=cune 521cdd96 => acl_get: [4] matched 521cdd96 => acl_get: [4] attr entry 521cdd96 => acl_mask: access to entry "qmailUID=2,ou=accounts,o=cune", attr "entry" requested 521cdd96 => acl_mask: to all values by "qmailGID=306,ou=accounts,o=cune", (=0) 521cdd96 <= check a_dn_pat: qmailGID=306,ou=accounts,o=cune 521cdd96 <= acl_mask: [1] applying none(=0) (stop) 521cdd96 <= acl_mask: [1] mask: none(=0) 521cdd96 => slap_access_allowed: read access denied by none(=0) 521cdd96 => access_allowed: no more rules 521cdd96 send_search_entry: conn 1004 access to entry (qmailUID=2,ou=accounts,o=cune) not allowed 521cdd96 send_ldap_result: conn=1004 op=1 p=3 521cdd96 send_ldap_result: err=0 matched="" text="" 521cdd96 send_ldap_response: msgid=2 tag=101 err=0 There is nothing special about the LDAP entry for Test.Entry. dn: qmailUID=2,ou=accounts,o=cune objectClass: pilotPerson objectClass: qmailUser objectClass: PureFTPdUser cn: Test Entry sn: Entry uid: Test.Entry qmailUID: 2 accountStatus: active mail: test.entry@cune.org userClass: stu Please let me know if you require any other information. Thank you. Russell Mosemann
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.
Russell.Mosemann@cune.edu wrote: > 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. Hmm, maybe it's related to this: http://www.openldap.org/its/index.cgi?findid=7495 Ciao, Michael.
> 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
The lookup succeeds, and the returned 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 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.
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:"Ti= > mes New Roman","serif"">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:"Ti= > mes New Roman","serif""><o:p> </o:p></span></p> > <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti= > mes New Roman","serif"">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:"Ti= > mes New Roman","serif""><o:p> </o:p></span></p> > <p class=3D"MsoNormal"><span style=3D"font-size:12.0pt;font-family:"Ti= > mes New Roman","serif"">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:"Ti= > mes New Roman","serif""><o:p> </o:p></span></p> > </div> > </body> > </html> > > --_000_B01302EA11DF7D40B2AD9CBEC71B02562C4A3ED5exchange2cunepr_-- > > > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano
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
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
Russell.Mosemann@cune.edu wrote: > 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. Did you already try with this? rwm-drop-unrequested-attrs no Ciao, Michael.
> 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
Mosemann, Russell wrote: >> 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. I had a similar issue myself before: http://www.openldap.org/its/index.cgi?findid=7495 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.
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/