Bug 975729 - [User Portal] Disable strict user checking - warning, confirmation and then error
[User Portal] Disable strict user checking - warning, confirmation and then e...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-userportal (Show other bugs)
3.2.0
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.4.0
Assigned To: Frantisek Kobzik
Pavel Novotny
virt
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-19 04:41 EDT by Jiri Belka
Modified: 2014-06-12 10:06 EDT (History)
10 users (show)

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


Attachments (Terms of Use)
engine.log (8.57 KB, application/x-gzip)
2013-06-19 04:47 EDT, Jiri Belka
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 18686 None None None Never

  None (edit)
Description Jiri Belka 2013-06-19 04:41:27 EDT
Description of problem:
When 'disabled strick user checking' is not set (default for Desktop VMs) and VM's console is opened by a user, another user would face following scenario when opening console of the same VM:

* 1st popup

There may be users connected to the console who will not be able to reconnect. Do you want to proceed?

* 2nd popup

Error while executing action:

jb-wxp:

Console connection denied. Another user has already accessed the console of this VM. The VM should be rebooted to allow another user to access it, or changed by an admin to not enforce reboot between users accessing its console.

This behaviour is quite bizarre. Why to cause a positive hope to the user and then rudely telling him he cannot take the console? :)

I would expect following behaviour:

~~ disable strict user checking not set (default for Desktop VM) ~~
* if another user has 'admin-like' roles just show him error
* if another user has 'admin-like' roles, show him confirmation popup and give him the console

~~ disable strict user checking is set ~~
* if another user has opened console, show him confirmation popup and give him the console

FYI, now if disable strict user checking is set, the confirmation popup is not shown at all.

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

How reproducible:
100%

Steps to Reproduce:
1. (disable strict user checking is not set) open console by user A
2. (disable strict user checking is not set) open console of the same VM by user B
3. (disable strict user checking is set) open console by user A
4. (disable strict user checking is set) opne console of the same VM by user B

Actual results:
2 - causes confirmation popup and then error popup
4 - opens console without any info that it has been already opened by user A

Expected results:
2 - if another user has 'admin-like' roles just show him error; if another user has 'admin-like' roles, show him confirmation popup and give him the console
4 - if another user has opened console, show him confirmation popup and give him the console

Additional info:
Comment 1 Jiri Belka 2013-06-19 04:47:07 EDT
Created attachment 762791 [details]
engine.log
Comment 2 Itamar Heim 2013-06-19 17:07:30 EDT
we can check if user has the permission to force connect, else, no point in showing the warning and we can just fail the user.
Comment 3 Jiri Belka 2013-06-21 05:49:09 EDT
FYI on sf18.1

* admin@internal opens console
* some user with userrole logs into User Portal and tries to open console, this results in canceling admin@internal's console session and getting console for this User Portal user

Either some low-privilege user should not get admin@internal console, or there should be a warning popup. Anyway, seems strange.
Comment 4 Juan Hernández 2013-06-24 04:58:22 EDT
I believe that the situation described in comment 3 can only happen if the user also has the RECONNECT_TO_VM permission, and in that case this is the expected behavior: the user can take the console regardless of who was connected before. Can you please double check this?
Comment 5 Jiri Belka 2013-06-25 03:48:50 EDT
UserRole does not have 'Override opened console session' which is probably mentioned RECONNECT_TO_VM permission. Thus my comment #3 is valid, this DOES apply to situation when user has just UserRole.
Comment 6 Juan Hernández 2013-06-28 10:47:29 EDT
I tested the situation described in comment 3 with the latest upstream master, which should be mostly identical to downstream 3.3, and the behavior is as I expected: the second user can't access the console. What version exactly are you using Jiri? May I suggest that you make sure that the UserRole hasn't been modified to add the "Override opened console session" permission, and try this again with a freshly added user, to make sure that it hasn't any other permissions.

I did reproduce the behavior in the description, and I agree this shouldn't happen. I think this is happening because in the "executeCommandWithConsoleSafenessWarning" method of the "ConsoleModel" class we are displaying the first warning when the user that currently has the console *does not* have the RECONNECT_TO_VM permission. Shouldn't be the logic that we display the warning when the user that is trying to open the console *does* have that permission? I mean, it is the current user that can change/break things if she/he has the permission. What do you think Fratisek?
Comment 7 Jiri Belka 2013-07-01 05:00:15 EDT
The BZ was reported for 3.2 (sf18).
Comment 8 Juan Hernández 2013-07-02 05:15:23 EDT
I tested the situation described in comment 3 with rhevm-3.2.1-0.31.el6ev and the behavior is as expected: the second user can't access the console.
Comment 9 Frantisek Kobzik 2013-08-28 07:25:37 EDT
@Juan:
Your point in comment #6 is indeed rational. However, in the original bz there a request for doing it this way (if currently connected user has no reconnect permission -> display the warning). I think I just add another check to the executeCommandWithSafenessWarning that checks if the currently logged portal user has reconnect permission and display the warning if he/she has has it (i.e. he/she can steal the console from a normal user, which could be harmful). If he/she doesn't have it, backend validation prevents opening the console.
Comment 10 Juan Hernández 2013-08-28 09:11:32 EDT
I think that this additional warning that you are proposing should be the only one, but you should probably discuss this with the product management and user experience teams.

Anyhow, if we continue to display this warning about the permissions of the other user, then we should only display it if the current user does have the power to steal the console. I mean something like this, with nicer messages, of course:

if (the this user can steal the console) {
  if (the other user can't steal the console) {
    warning(
      You are about to steal the console from an user which
      won't be able to steal it from you
    )
  }
  else {
    warning(
      You are bout to steal the console from an user, and he/she
      may steal it from you later
    )
  }
}
Comment 11 Juan Hernández 2013-08-28 09:14:51 EDT
There is a related discussion about these warnings in bug 1001625.
Comment 12 Frantisek Kobzik 2013-08-28 09:50:40 EDT
about comment 10:
I'm not sure about information value of the "else" branch. Anybody with reconnect permission can steal from the user no matter who he/she is, right?
Comment 13 Juan Hernández 2013-08-28 11:04:22 EDT
Correct, any user with the permission can steal the console, not only the current one.
Comment 14 Frantisek Kobzik 2013-09-26 04:40:55 EDT
merged u/s: 78daa289a7d893b92aee6c81298308e5bfde5390
Comment 15 Sandro Bonazzola 2014-01-14 03:44:07 EST
ovirt 3.4.0 alpha has been released
Comment 16 Pavel Novotny 2014-02-19 12:52:42 EST
Verified in ovirt-engine-3.4.0-0.7.beta2.el6.noarch.

Verification steps:
Terminology:
- user A: privileged user, i.e., has permission "Override opened console session"
- user B: unprivileged user, i.e., has not permission "Override opened console session"

1) A running VM with *unchecked* "Disable strict user checking".
  1a. User A opens the console, then user B opens the console.
  1b. User B opens the console, then user A opens the console.
2) A running VM with *checked* "Disable strict user checking".
  2a. User A opens the console, then user B opens the console.
  2b. User B opens the console, then user A opens the console.

Results:
1a) User B gets error dialog and cannot "steal" the console from user A.
-~-
Error while executing action:

F19:

    Console connection denied. Another user has already accessed the console of this VM. The VM should be rebooted to allow another user to access it, or changed by an admin to not enforce reboot between users accessing its console.
-~-

1b) User A gets confirmation dialog and then can "steal" the console from user B.
-~-
There may be users connected to the console who will not be able to reconnect.
Do you want to proceed?
-~-

2a) and 2b) Same results. User verification is disabled so user B can "steal" console from user A and vice versa. Also no dialog is displayed beforehand for none of the two users. If user wants to be notified, then the user checking should be enabled.
Comment 17 Itamar Heim 2014-06-12 10:06:10 EDT
Closing as part of 3.4.0

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