Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
First Last Prev Next    This bug is not in your last search results.
Bug 1427987 - [downstream clone - 4.1.1] Provide a configuration to enable that user actions should succeed regardless of 'filter' parameter
[downstream clone - 4.1.1] Provide a configuration to enable that user action...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity medium
: ovirt-4.1.1-1
: ---
Assigned To: Juan Hernández
Aleksei Slaikovskii
: ZStream
Depends On: 1420310
Blocks:
  Show dependency tree / graph
 
Reported: 2017-03-01 11:17 EST by rhev-integ
Modified: 2017-04-24 21:12 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
The API supports the 'filter' parameter to indicate if results should be filtered according to the permissions of the user. Due to the way this is implemented, non admin users need to set this parameter for almost all operations because the default value is 'false'. To simplify things for non admin users, a configuration option ENGINE_API_FILTER_BY_DEFAULT has been added which allows you to change the default value to 'true', but only for non admin users. If the value is explicitly given in a request it will be honoured. If you change the value of ENGINE_API_FILTER_BY_DEFAULT to 'true', be aware that this is not backwards compatible, as clients that used non admin users and did not explicitly provide the 'filter' parameter will start to behave differently. However, this is unlikely because calls from non admin users without 'filter=true' is almost useless. If it is necessary to change the default behaviour, it can be achieved by changing this parameter in a configuration file inside the '/etc/ovirt-engine/engine.conf.d' directory. For example: # echo 'ENGINE_API_FILTER_BY_DEFAULT="true"' > \ /etc/ovirt-engine/engine.conf.d/99-filter-by-default.conf # systemctl restart ovirt-engine
Story Points: ---
Clone Of: 1420310
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Python SDK StorageAdmin disk creation (670 bytes, text/plain)
2017-04-10 06:52 EDT, Aleksei Slaikovskii 		no flags Details
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 73039 master MERGED restapi: Set 'filter=true' by default for non admins 2017-03-01 11:17 EST
oVirt gerrit 73396 ovirt-engine-4.1 MERGED restapi: Set 'filter=true' by default for non admins 2017-03-01 16:43 EST
oVirt gerrit 73397 ovirt-engine-4.1 MERGED restapi: Disable filtering by default for non-admin users 2017-03-01 16:43 EST
oVirt gerrit 74173 ovirt-engine-4.1.1.z MERGED restapi: Set 'filter=true' by default for non admins 2017-03-19 06:16 EDT
oVirt gerrit 74174 ovirt-engine-4.1.1.z MERGED restapi: Disable filtering by default for non-admin users 2017-03-19 06:17 EDT
Red Hat Product Errata RHEA-2017:0997 normal SHIPPED_LIVE Red Hat Virtualization Manager (ovirt-engine) 4.1 GA 2017-04-18 16:11:26 EDT

  None (edit)
Description rhev-integ 2017-03-01 11:17:25 EST 
+++ This bug is an upstream to downstream clone. The original bug is: +++
+++   bug 1420310 +++
======================================================================

Description of problem:
When a rest-api action is invoked by a user without providing 'filter' parameter, it may fail due to insufficient permissions for the internal queries.
This is problematic for the python sdk which supports 'filter' argument only for service listing (and not for actions).

E.g.
Creating a disk using sdk-python fails due to insufficient permissions for GetStorageDomainListByIdQuery / GetStorageDomainByIdQuery:

disk = disks_service.add(
    disk=types.Disk(
        name='mydisk',
        description='My disk',
        format=types.DiskFormat.RAW,
        provisioned_size=2 * 2**30,
        storage_domains=[
            types.StorageDomain(
                id='43b457ae-e3b6-434d-8a9f-b234b1976e5f',
            ),
        ],
    )
)

Version-Release number of selected component (if applicable):
4.1

How reproducible:
100%

Actual results:
Fails on 'Query execution failed due to insufficient permissions.'

Expected results:
Should succeed if the user has sufficient permissions to perform the action.

(Originally by Daniel Erez)
Comment 1 rhev-integ 2017-03-01 11:17:33 EST 
Juan is trying to find a definitive solution for that, so targetting now to 4.2 and we can decide to retarget when we have solution ready

(Originally by Martin Perina)
Comment 3 rhev-integ 2017-03-01 11:17:39 EST 
There are many possible solutions to this, all of them quite complicated. The long term solution should be to remove the 'filter' concept and just make all queries filter the results according to the permissions of the user, by default. But doing that is a very large task, far beyond what can be done in the API. The only reasonable solution to this that I see is to make set 'filter=true' the default for non admin users. That is what the proposed patch does. As that is a backwards compatibility breaking change, it also introduces a configuration parameter to revert to the old behavior, for the few cases where the old behavior will actually be needed.

(Originally by juan.hernandez)
Comment 4 rhev-integ 2017-03-01 11:17:45 EST 
This could also be back-ported, changing the default value of the parameter to 'false'.

(Originally by juan.hernandez)
Comment 8 Martin Perina 2017-03-17 15:57:05 EDT 
It missed 4.1.1.5 build
Comment 9 Aleksei Slaikovskii 2017-04-10 06:52 EDT 
Created attachment 1270457 [details]
Python SDK StorageAdmin disk creation

Verified on ovirt-engine-4.1.1.8-0.1.el7.noarch, python-ovirt-engine-sdk4-4.1.3-1.el7ev.x86_64
Comment 10 Juan Hernández 2017-04-13 16:36:41 EDT 
Byron, I did an small edit to the doc text to remove the "this patch ..." words, as that make sense in the description of the patch, but not in the release note. I'd appreciate if you can review the text again.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.