Description of problem: By default VMs do not allow console reconnect (thus 'Disable use strict checking' is not-checked'). engine=# select vm_name,vm_guid,allow_console_reconnect,console_disconnect_action from vms where vm_name = 'jb-w7-x86'; vm_name | vm_guid | allow_console_reconnect | console_disconnect_action -----------+--------------------------------------+-------------------------+--------------------------- jb-w7-x86 | 8d809727-1f36-4633-b0da-9ea71cd66182 | f | NONE (1 row) Thus if an user (eg. my AD user - ad-w2k12r2) opens spice console in User Portal, close the spice console and admin@internal opens spice console, "console session" is assigned to admin@internal: engine=# select username from users where user_id = (select console_user_id from vm_dynamic where vm_guid = '8d809727-1f36-4633-b0da-9ea71cd66182' ); username ---------- admin (1 row) Thus it used to work in a way that later on any user could not open again spice console from User Portal (allow_console_reconnect = false). But in 3.6-beta my user 'ad-w2k12r2' _CAN_ open console after admin@internal opened that. It is even worse, while admin@internal has still the console opened, ad-w2k12r2 can open spice console from User Portal and thus he can practically steal open session and get whatever user priviledge admin@internal has been in that time using. After AD user "steals" the spice console (original admin@internal's console gets closed; I had both users logged in on same client pc). engine=# select username from users where user_id = (select console_user_id from vm_dynamic where vm_guid = '8d809727-1f36-4633-b0da-9ea71cd66182' ); username ------------ ad-w2k12r2 (1 row) Version-Release number of selected component (if applicable): rhevm-backend-3.6.1.3-0.1.el6.noarch How reproducible: 100% Steps to Reproduce: 1. 1 vm assinged to an user with UserRole so he can open via User Portal 2. user in User Portal opens spice console of the vm and close it 3. admin@internal opens console from Admin Portal 4. user in User Portal opens spice console (admin@internal has still the spice console opened) Actual results: user in User Portal is able to access desktop of a VM while admin@internal is working with it Expected results: if admin@internal opens already opened spice console of an User Portal user, he replaces current session (it is written to db) and thus an User Portal use should not open the same spice console until reboot Additional info: " Click the Advanced Parameters arrow and select the check box to use this option. With this option selected, the virtual machine does not need to be rebooted when a different user connects to it. By default, strict checking is enabled so that only one user can connect to the console of a virtual machine. No other user is able to open a console to the same virtual machine until it has been rebooted. The exception is that a SuperUser can connect at any time and replace a existing connection. When a SuperUser has connected, no normal user can connect again until the virtual machine is rebooted. Disable strict checking with caution, because you can expose the previous user's session to the new user. "
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Another steps to Reproduce: 1. 1 vm assinged to an user with UserRole so he can open via User Portal 2. user in User Portal opens spice console of the vm 3. another user with UserRole to the same VM 4. the latter user in User Portal opens spice console (the former user has still the spice console opened) 4 = you will probably face https://bugzilla.redhat.com/show_bug.cgi?id=1311060 but iiuc currently the code does not check 'allow_console_reconnect'; if it is False (the default) then behaviour described as 'Additional info' in #0 applies. Thus ordinary users should not be allowed to open console of other users of same VM by default. FYI this was discovered while investigation why opening console with 2nd user causes ctrl-alt-del combo press in the VM guest. Example from guest agent which caused ctrl-alt-del combo press after VmLogonVDSCommand (??) from engine0. Dummy-2::INFO::2016-02-23 11:02:03,187::OVirtAgentLogic::296::root::Received an external command: login... Dummy-2::DEBUG::2016-02-23 11:02:03,187::OVirtAgentLogic::330::root::User log-in (credentials = '\x00\x00\x001ad-w2k12r2.com********\x00') Dummy-2::DEBUG::2016-02-23 11:02:03,187::GuestAgentWin32::261::root::Simulating a secure attention sequence (SAS). Dummy-2::ERROR::2016-02-23 11:02:04,203::GuestAgentWin32::289::root::Error writing credentials to pipe [1/3] (error = 2) Dummy-2::ERROR::2016-02-23 11:02:05,203::GuestAgentWin32::289::root::Error writing credentials to pipe [2/3] (error = 2) Dummy-2::ERROR::2016-02-23 11:02:06,203::GuestAgentWin32::289::root::Error writing credentials to pipe [3/3] (error = 2) Dummy-2::DEBUG::2016-02-23 11:02:06,203::OVirtAgentLogic::270::root::AgentLogicBase::doListen() - in loop before vio.read
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.
looks half-fixed, half-broken. But the "security" problem is resolved, so deferring to 3.6.5
Bugs moved pre-mature to ON_QA since they didn't have target release. Notice that only bugs with a set target release will move to ON_QA.
ok, 3.6.5.3-0.1.el6.noarch works as expected, users can't steal their consoles by default (allow_console_reconnect = f).