Bug 1015856 - Add Non-Existent User To Internal Domain - No Validation
Add Non-Existent User To Internal Domain - No Validation
Status: CLOSED DUPLICATE of bug 1100321
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: 3.5.0
Assigned To: Ori Liel
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2013-10-06 05:02 EDT by Ori Liel
Modified: 2016-02-10 14:23 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-20 12:20:20 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ori Liel 2013-10-06 05:02:23 EDT

'Add User' lets the client select an existing user from a configured domain in the system (e.g: active-directory, ldap, internal domain) and add it to the ovirt configuration. To specify the user, the client supplies user-id.

In 'internal' domain there is only one, pre-defined, user, which is: 'admin'. 

The bug: 

If client adds a user to 'internal' domains, then, since there is only one possible user in this domain ('admin'), the id which the client has supplied is ignored, and the engine assumes that the client meant 'admin'. 

But this can lead to confusing behaviour. If the client gave a different ID - perhaps thinking that he's creating a new user in 'internal' domain, the result will be adding the user 'admin' (which almost always exists already). 

The correct behaviour is - if client adds a user to 'internal' domain, and the ID of this user is not equal to the ID for 'admin', fail the action and supply a meaningful validation message.
Comment 1 Barak 2014-03-31 06:18:21 EDT
Going forward we'll have an internal JDBC provider,
Based on the the AAA work done for 3.5,

Hence moving to 3.5, as this is low priority and even when called this API does not do any damage.
Comment 2 Ori Liel 2014-03-31 06:28:15 EDT
The problem is that InternalDirectory-->queryUsers(String query) always returns admin@internal, ignoring the query string. 

Since refactoring is expected this area in 3.5, it did not seem worth it to fix now and risk 'noise' (considering also the low priority of the bug). 

Another possibility was to add a hard-coded validation in the API, but that would be a wrong approach - after engine changes we would be stuck with a redundant - if not wrong, by then, validation.
Comment 3 Juan Hernández 2014-06-20 12:20:20 EDT

*** This bug has been marked as a duplicate of bug 1100321 ***

Note You need to log in before you can comment on or make changes to this bug.