Bug 1172187
Summary: | [aaa] two ldap external providers have same id assigned, when one is incorrectly configured | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ondra Machacek <omachace> | ||||
Component: | ovirt-engine-restapi | Assignee: | Yair Zaslavsky <yzaslavs> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ondra Machacek <omachace> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 3.5.0 | CC: | alonbl, bazulay, ecohen, gklein, iheim, lpeer, lsurette, omachace, oourfali, rbalakri, Rhev-m-bugs, sherold, yeylon | ||||
Target Milestone: | --- | ||||||
Target Release: | 3.5.0 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | infra | ||||||
Fixed In Version: | org.ovirt.engine-root-3.5.0-26 | Doc Type: | Bug Fix | ||||
Doc Text: |
Cause:
When having two (or more domain names) with the same prefix, and the prefix is long enough, the two domains will have the same id when accessing rest-api (using for example /api/domains)
Consequence:
As a result, it is impossible to add users/groups from these domains
Fix:
The fix is to generate the id from the entire string (using base64 encoding) and not just from the first part (the first 16 bytes of a byte array that holds the characters of the string).
Result:
Any external application that depends on the IDs should reset them, as after upgrade the IDS generation is changed.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2015-02-11 20:56:10 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: | |||||||
Bug Blocks: | 1076964 | ||||||
Attachments: |
|
<domains><domain href="/api/domains/696e7465-726e-616c-696e-7465726e616c" id="696e7465-726e-616c-696e-7465726e616c"><name>internal</name><link href="/api/domains/696e7465-726e-616c-696e-7465726e616c/users" rel="users"/><link href="/api/domains/696e7465-726e-616c-696e-7465726e616c/groups" rel="groups"/><link href="/api/domains/696e7465-726e-616c-696e-7465726e616c/users?search={query}" rel="users/search"/><link href="/api/domains/696e7465-726e-616c-696e-7465726e616c/groups?search={query}" rel="groups/search"/></domain><domain href="/api/domains/6c646170-2d61-7574-687a-2d746573745f" id="6c646170-2d61-7574-687a-2d746573745f"><name>ldap-authz-test_digest_ad</name><link href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/users" rel="users"/><link href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/groups" rel="groups"/><link href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/users?search={query}" rel="users/search"/><link href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/groups?search={query}" rel="groups/search"/></domain><domain href="/api/domains/6c646170-2d61-7574-687a-2d746573745f" id="6c646170-2d61-7574-687a-2d746573745f"><name>ldap-authz-test_gssapi_ipa</name><link href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/users" rel="users"/><link href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/groups" rel="groups"/><link href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/users?search={query}" rel="users/search"/><link href="/api/domains/6c646170-2d61-7574-687a-2d746573745f/groups?search={query}" rel="groups/search"/></domain></domains> took me a while to understand what is "same id"... the restapi domain id 6c646170-2d61-7574-687a-2d746573745f. interesting this is gui... while I thought we took care of it using the hex encoded string, but now I understand we took care of user id, so this is leftover ever since 3.4. solution may be similar to domains as well, the guid should be replaced with hex encoded authz name. any other option? (In reply to Alon Bar-Lev from comment #3) > took me a while to understand what is "same id"... the restapi domain id > 6c646170-2d61-7574-687a-2d746573745f. > > interesting this is gui... while I thought we took care of it using the hex > encoded string, but now I understand we took care of user id, so this is > leftover ever since 3.4. > > solution may be similar to domains as well, the guid should be replaced with > hex encoded authz name. > > any other option? The hex combination is for the "entry id" - i.e group or principal. Domain has no real id, and it's generated by performing - Guid(str.getBytes() where str == domain name. If you have two profiles with the same authz, you will reach in REST-API two "domains" with same "id". So actually, it's API only, not even GUI. (In reply to Yair Zaslavsky from comment #4) > So actually, it's API only, not even GUI. sure it is api only. but you cannot convert string into Guid. we need similar representation for the domain id based on authz name, not sure from above response if it is progressing or discussion. In addition, as the REST-API code usages only the first X bytes of each domain name for the domain id, two domain names with same prefix may yield the same domain id, so the hex encoding should be used as stated above (this is actually the scenario at the bug). Domains with same prefix has now diffrent domain ID in REST. Doesn't work in CLI. list users --query "" --domain-identifier "6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D" > /tmp/cli_output.tmp' Debug and Error raw output: send: 'GET /api/domains HTTP/1.1\r\nHost: jenkins-vm-06.scl.lab.tlv.redhat.com\r\nAccept-Encoding: identity\r\nSession-TTL: 3600\r\nPrefer: persistent-auth\r\nAccept: application/xml\r\nFilter: False\r\ncookie: JSESSIONID=CCCXXXXXXXXXXXx\r\nContent-type: application/xml\r\nAuthorization: Basic XXXXXXXXXX\r\n\r\n' reply: 'HTTP/1.1 200 OK\r\n' header: Date: Mon, 22 Dec 2014 16:54:19 GMT header: Pragma: No-cache header: Cache-Control: no-cache header: Expires: Thu, 01 Jan 1970 02:00:00 IST header: JSESSIONID: XXXXXXXXXXXXXXXXXXXXXXXX header: Content-Type: application/xml header: Content-Length: 6027 header: Vary: Accept-Encoding header: Connection: close body: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <domains> <domain href="/api/domains/61642D77326B313272322E726865762E6C61622E656E672E6272712E7265646861742E636F6D" id="61642D77326B313272322E726865762E6C61622E656E672E6272712E7265646861742E636F6D"> <name>ad-w2k12r2.rhev.lab.eng.brq.redhat.com</name> <link href="/api/domains/61642D77326B313272322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users" rel="users"/> <link href="/api/domains/61642D77326B313272322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups" rel="groups"/> <link href="/api/domains/61642D77326B313272322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users?search={query}" rel="users/search"/> <link href="/api/domains/61642D77326B313272322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups?search={query}" rel="groups/search"/> </domain> <domain href="/api/domains/61642D77326B3872322E726865762E6C61622E656E672E6272712E7265646861742E636F6D" id="61642D77326B3872322E726865762E6C61622E656E672E6272712E7265646861742E636F6D"> <name>ad-w2k8r2.rhev.lab.eng.brq.redhat.com</name> <link href="/api/domains/61642D77326B3872322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users" rel="users"/> <link href="/api/domains/61642D77326B3872322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups" rel="groups"/> <link href="/api/domains/61642D77326B3872322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users?search={query}" rel="users/search"/> <link href="/api/domains/61642D77326B3872322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups?search={query}" rel="groups/search"/> </domain> <domain href="/api/domains/6164322E726865762E6C61622E656E672E6272712E7265646861742E636F6D" id="6164322E726865762E6C61622E656E672E6272712E7265646861742E636F6D"> <name>ad2.rhev.lab.eng.brq.redhat.com</name> <link href="/api/domains/6164322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users" rel="users"/> <link href="/api/domains/6164322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups" rel="groups"/> <link href="/api/domains/6164322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users?search={query}" rel="users/search"/> <link href="/api/domains/6164322E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups?search={query}" rel="groups/search"/> </domain> <domain href="/api/domains/6272712D6970612E726865762E6C61622E656E672E6272712E7265646861742E636F6D" id="6272712D6970612E726865762E6C61622E656E672E6272712E7265646861742E636F6D"> <name>brq-ipa.rhev.lab.eng.brq.redhat.com</name> <link href="/api/domains/6272712D6970612E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users" rel="users"/> <link href="/api/domains/6272712D6970612E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups" rel="groups"/> <link href="/api/domains/6272712D6970612E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users?search={query}" rel="users/search"/> <link href="/api/domains/6272712D6970612E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups?search={query}" rel="groups/search"/> </domain> <domain href="/api/domains/6272712D6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D" id="6272712D6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D"> <name>brq-ldap.rhev.lab.eng.brq.redhat.com</name> <link href="/api/domains/6272712D6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users" rel="users"/> <link href="/api/domains/6272712D6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups" rel="groups"/> <link href="/api/domains/6272712D6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users?search={query}" rel="users/search"/> <link href="/api/domains/6272712D6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups?search={query}" rel="groups/search"/> </domain> <domain href="/api/domains/6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D" id="6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D"> <name>brq-openldap.rhev.lab.eng.brq.redhat.com</name> <link href="/api/domains/6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users" rel="users"/> <link href="/api/domains/6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups" rel="groups"/> <link href="/api/domains/6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D/users?search={query}" rel="users/search"/> <link href="/api/domains/6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D/groups?search={query}" rel="groups/search"/> </domain> <domain href="/api/domains/696E7465726E616C" id="696E7465726E616C"> <name>internal</name> <link href="/api/domains/696E7465726E616C/users" rel="users"/> <link href="/api/domains/696E7465726E616C/groups" rel="groups"/> <link href="/api/domains/696E7465726E616C/users?search={query}" rel="users/search"/> <link href="/api/domains/696E7465726E616C/groups?search={query}" rel="groups/search"/> </domain> <domain href="/api/domains/71612E6C61622E746C762E7265646861742E636F6D" id="71612E6C61622E746C762E7265646861742E636F6D"> <name>qa.lab.tlv.redhat.com</name> <link href="/api/domains/71612E6C61622E746C762E7265646861742E636F6D/users" rel="users"/> <link href="/api/domains/71612E6C61622E746C762E7265646861742E636F6D/groups" rel="groups"/> <link href="/api/domains/71612E6C61622E746C762E7265646861742E636F6D/users?search={query}" rel="users/search"/> <link href="/api/domains/71612E6C61622E746C762E7265646861742E636F6D/groups?search={query}" rel="groups/search"/> </domain> </domains> domain 6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D does not exist. please comment the upstream bugs, downstream are just for process. (In reply to Alon Bar-Lev from comment #9) > please comment the upstream bugs, downstream are just for process. oh... there is no upstream bug, what a mess of release engineering... I hope someone will wake up. Ondra, are you sure this is not bug in the cli? I can see that all ids are correct. To check if id is valid use the following command, the output should be the authz name. $ python -c "import sys, base64; print(base64.b16decode(sys.argv[1]).decode('utf8'))" 6272712D6F70656E6C6461702E726865762E6C61622E656E672E6272712E7265646861742E636F6D brq-openldap.rhev.lab.eng.brq.redhat.com Yes it is. There is uuid conversion (uuid.UUID(string)), which doesn't work for such string. I'll open bug for CLI. (In reply to Ondra Machacek from comment #13) > Yes it is. There is uuid conversion (uuid.UUID(string)), which doesn't work > for > such string. I'll open bug for CLI. strange, ids should be handled as-is without assumptions unless rsdl instructs. please also check the id within /user/domains/<id>/users/<id> as it should suffer from same. There is code to tranfers id into name if the conversion into UUID fails. You can see src/ovirtcli/command/command.py line 69. /user/domains/<id>/users/<id> show user --domain-identifier "6164322E726865762E6C61622E656E672E6272712E7265646861742E636F6D" --id "39343934396564392D366433642D343437362D613932392D356439363730386635333733" domain 6164322E726865762E6C61622E656E672E6272712E7265646861742E636F6D does not exist. Fails on same, since it first tries to find domain. |
Created attachment 966302 [details] extensions properties Description of problem: Version-Release number of selected component (if applicable): vt13.1 How reproducible: always Steps to Reproduce: 0. install ovirt-engine-extension-aaa-ldap 1. extract properties from attachment properties.tar.gz into /etc/ovirt-engine/extensions.d 2. service ovirt-engine restart 3. GET /api/domains/ Actual results: both domains have same id Expected results: domains have different id Additional info: