Bug 1096175

Summary:	[AAA] Support some special characters in users/groups/domains search query
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Anand Nande <anande>
Component:	ovirt-engine	Assignee:	Eli Mesika <emesika>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ondra Machacek <omachace>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.3.0	CC:	anande, bazulay, eedri, emesika, gklein, iheim, lpeer, lsurette, mgoldboi, mperina, nashok, omachace, oourfali, pstehlik, rbalakri, Rhev-m-bugs, sherold, srevivo, ykaul
Target Milestone:	ovirt-3.5.5	Keywords:	ZStream
Target Release:	3.5.5	Flags:	mgoldboi: Triaged+
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: unsupported characters in user search Consequence: Search with a space or special character in object name gives no results Fix: Support the following: space - supported only for the namespace(namingContext) * - can be searched by ** & - Not supported ! - Not supported ^ - Not supported & - Not supported ) - Not supported = - Not supported ' - Not supported " - Not supported < - Not supported > - Not supported Not all ldap providers support these special characters in users/group name. All other special characters except that listed are supported by search engine. Result: You can use now space and the special characters as described above	Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-20 01:11:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1148797
Bug Blocks:	1076964, 1186039, 1221302

Comment 2 Alon Bar-Lev 2014-12-30 09:50:45 UTC

the problem is within the backend general search, I consider this a bug and not rfe.

this is actually a dup of bug#1148797.

2014-12-30 11:42:37,145 INFO  [org.ovirt.engine.core.bll.SearchQuery] (http--0.0.0.0-8080-4) [] ResourceManager::searchBusinessObjects - erroneous search text - ''ADUSER: allnames=#alon*''
2014-12-30 11:42:37,146 INFO  [org.ovirt.engine.core.bll.SearchQuery] (http--0.0.0.0-8080-4) [] ResourceManager::searchBusinessObjects - erroneous search text - ''ADGROUP: name=#alon*''

Comment 8 Alon Bar-Lev 2015-02-24 06:46:35 UTC

(In reply to Yair Zaslavsky from comment #7)
> Alon, for 3.5 (and above) do we want to fix this at general ldap component?
> What about backport for older versions? is this required?

as I wrote in comment#2, this has nothing to do with extension.
something at core is not parsing queries correctly.

Comment 16 Liran Zelkha 2015-05-19 05:16:30 UTC

According to the LDAP spec, # has a special meaning, as it uses for hex string representations (https://tools.ietf.org/html/rfc4514).
I would suggest escaping the # and updating ADSyntaxChecker accordingly (meaning, the user writes \#, and our RegExp is updated accordingly)

Comment 17 Alon Bar-Lev 2015-05-19 05:21:00 UTC

(In reply to Liran Zelkha from comment #16)
> According to the LDAP spec, # has a special meaning, as it uses for hex
> string representations (https://tools.ietf.org/html/rfc4514).
> I would suggest escaping the # and updating ADSyntaxChecker accordingly
> (meaning, the user writes \#, and our RegExp is updated accordingly)

The search should not effect the underline provider consideration. Engine should not assume anything as it does not know what is actually queried (ldap, database, file, etc...).

Comment 23 Eli Mesika 2015-06-22 13:31:21 UTC

*** Bug 1148797 has been marked as a duplicate of this bug. ***

Comment 24 Eli Mesika 2015-06-22 13:52:26 UTC

Currently escape characters documented in http://www.zytrax.com/books/ldap/apa/search.html are not supported 

"If you need to search for a pattern that includes a special character (* ) ( \ or NULL) it must be escaped using the format '\code' (the code is actually the 2 hexadecimal characters representing the ASCII character). Similarly any binary value may be search for by using its hexadecimal value."

\2a replaces or escapes *
\28 replaces or escapes (
\29 replaces or escapes )
\5c replaces or escapes \

If you think this is mandatory, please open a separate BZ for that

Comment 25 Alon Bar-Lev 2015-06-22 15:10:25 UTC

(In reply to Eli Mesika from comment #24)
> Currently escape characters documented in
> http://www.zytrax.com/books/ldap/apa/search.html are not supported 
> 
> "If you need to search for a pattern that includes a special character (* )
> ( \ or NULL) it must be escaped using the format '\code' (the code is
> actually the 2 hexadecimal characters representing the ASCII character).
> Similarly any binary value may be search for by using its hexadecimal value."
> 
> \2a replaces or escapes *
> \28 replaces or escapes (
> \29 replaces or escapes )
> \5c replaces or escapes \
> 
> If you think this is mandatory, please open a separate BZ for that

this is done within provider.

which provider have you tested with?

Comment 26 Eli Mesika 2015-06-22 15:58:34 UTC

(In reply to Alon Bar-Lev from comment #25)
> 
> this is done within provider.
> 
> which provider have you tested with?

RHDS

Comment 27 Alon Bar-Lev 2015-06-22 16:03:05 UTC

(In reply to Eli Mesika from comment #26)
> (In reply to Alon Bar-Lev from comment #25)
> > 
> > this is done within provider.
> > 
> > which provider have you tested with?
> 
> RHDS

legacy and unsupported (kerbldap)
new and supported (ovirt-engine-extension-aaa-ldap)

Comment 28 Max Kovgan 2015-06-28 14:12:38 UTC

ovirt-3.6.0-3 release

Comment 30 Eyal Edri 2015-07-01 12:56:43 UTC

i dont see any 3.5 patch attached to the bug, can you add it?

Comment 32 Oved Ourfali 2015-07-12 06:04:46 UTC

*** Bug 1221302 has been marked as a duplicate of this bug. ***

Comment 36 Eyal Edri 2015-07-29 11:53:28 UTC

no, its not in the 3.5.4 branch and should be removed from the errata:
https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=shortlog;h=refs%2Fheads%2Fovirt-engine-3.5.4

Comment 37 Eyal Edri 2015-07-29 11:55:06 UTC

removed it from the errata.

Comment 39 Oved Ourfali 2015-09-21 13:04:14 UTC

Anand - See question on Bug 1148797.
If the answer is no, this bug will have to move to 4.0.

Comment 40 Oved Ourfali 2015-09-24 11:10:38 UTC

Verified with Anand that this is enough to cover the tickets.

Comment 41 Eyal Edri 2015-10-12 17:36:40 UTC

setting missing ovirt-3.5.5 milestone for 3.5.5 bugs.