Description of problem: When trying to create the API without filter=True using a user account, I am getting "query execution failed due to insufficient permissions." Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. initialize API without filter=True, with user account credentials API(self.uri, self.username, self.password, ca_file = self.ca_file, debug = True) Actual results: send: 'GET /api HTTP/1.1\r\nHost: <host>.redhat.com\r\nAccept-Encoding: identity\r\nFilter: False\r\nPrefer: persistent-auth\r\nContent-type: application/xml\r\nAccept: application/xml\r\nAuthorization: Basic <I'm not sharing my password>==\r\n\r\n' reply: 'HTTP/1.1 400 Bad Request\r\n' header: Date: Tue, 04 Nov 2014 14:31:52 GMT header: JSESSIONID: w9ZGVyIVoOGKIXdjuesJ4bBi header: Content-Type: application/xml header: Content-Length: 188 header: Vary: Accept-Encoding header: Connection: close Traceback (most recent call last): File "./make_vm_template.py", line 37, in <module> rhev_m_conn = rhevm.Rhevm(location=options.location) File "/home/pspacek/rhev/rhevm.py", line 73, in __init__ self.connect_api() File "/home/pspacek/rhev/rhevm.py", line 101, in connect_api api = rhevm_api(self.uri, self.username, self.password, ca_file = self.ca_file, debug = True) File "/usr/lib/python2.6/site-packages/ovirtsdk/api.py", line 145, in __init__ url='' File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/proxy.py", line 118, in request persistent_auth=self._persistent_auth) File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/proxy.py", line 140, in __doRequest persistent_auth=persistent_auth File "/usr/lib/python2.6/site-packages/ovirtsdk/web/connection.py", line 134, in doRequest raise RequestError, response ovirtsdk.infrastructure.errors.RequestError: status: 400 reason: Bad Request detail: query execution failed due to insufficient permissions. Expected results: Initialization of the api does not fail. Additional info:
The reason for this is that the Python SDK requests the /api URI as part of the connection process. When this is requested by a normal (non admin) user without the "Filter: true" header the RESTAPI will request to the backend information like the RPM version, using GetConfigurationValueQuery, and the Backend.runQuery method. But even if the requested parameter is marked as allowed for normal users the query will fail because there is a previous check (in QueriesCommandBase.validatePermissions) that rejects any non-filtered query from normal users. This could be fixed changing the RESTAPI to use the Backend.runPublicQuery method when the user is a normal (non admin) user. But the RESTAPI doesn't know (and shouldn't know, in my opinion) if the user is normal or admin. The right solution for this is that the backend should do a fine grained check, and accept and respond requests for configuration parameters that are allowed for users regardless of the filtering/not-filtering setting.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Whether you're an admin or not is NOT exposed to the REST-API. We will not change the default to use the filtered view, as this view has several restrictions (one of which is that search isn't supported on it). Only when we introduce global roles (currently that's not planned for 4.0), we will be able to ask the SSO service whether the user is admin, and act upon that. Ideally, the engine should show you the view you can see, based on who you are, but that will means that the same user, if he is an admin, will always see all objects. If organizations use "root"-kind user to access admin API/portal, and their own user for user-related requests, then it will work. However, if the organization is used to people working with their own users, then it will be a regression to them. My gut feeling is to close this one as WONTFIX. However, as we might introduce global roles in 4.1, I'm now pushing it forward, for consideration in 4.1.
I don't see us investing in this one. Closing as WONTFIX.