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:
Created attachment 762791 [details] engine.log
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.
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.
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?
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.
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?
The BZ was reported for 3.2 (sf18).
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.
@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.
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 ) } }
There is a related discussion about these warnings in bug 1001625.
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?
Correct, any user with the permission can steal the console, not only the current one.
merged u/s: 78daa289a7d893b92aee6c81298308e5bfde5390
ovirt 3.4.0 alpha has been released
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.
Closing as part of 3.4.0