Bug 1264391 - vmconsole specific role should be assigned to enable vmconsole access
vmconsole specific role should be assigned to enable vmconsole access
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: VMConsole (Show other bugs)
---
Unspecified Unspecified
high Severity high (vote)
: ovirt-3.6.1
: 3.6.1
Assigned To: Ravi Nori
Nikolai Sednev
virt
: Triaged
Depends On:
Blocks: 1223671
  Show dependency treegraph
 
Reported: 2015-09-18 06:46 EDT by Alon Bar-Lev
Modified: 2016-02-10 14:24 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-16 07:20:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑3.6.z+
mgoldboi: planning_ack+
michal.skrivanek: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 46379 master MERGED engine : vmconsole permissions violates engine permission scheme Never
oVirt gerrit 47190 ovirt-engine-3.6 MERGED engine : vmconsole permissions violates engine permission scheme Never
oVirt gerrit 48799 master ABANDONED engine : Reducing complexity of vmconsole query Never
oVirt gerrit 48828 ovirt-engine-3.6 MERGED engine : Remove SessionDataContainer injection LoginOnBehalfCommand Never

  None (edit)
Description Alon Bar-Lev 2015-09-18 06:46:06 EDT
Currently the UserRole is used to enable vmconsole access.

However, unlike spice/vnc there is no user agent to manage logout when session disconnect and there is no semaphore mechanism to limit only previously logged in user to attempt reconnection.

The access to vmconsole is required for sysadmin as a mean of recovery if network is lost or various monitoring solutions, it is not usable for end-users.

Session semaphore cannot be applied because of the sysadmin/monitoring solution use case in which a session sharing is required, even if disconnect happens.

This means that access to serial console is more sensitive than accessing spice/vnc and a different role should be applied.
Comment 1 Michal Skrivanek 2015-09-18 07:06:05 EDT
we plan to use UserVmManager role with a new action group to be able to access/allow the user with a configured ssh key to access the VM
Comment 2 Alon Bar-Lev 2015-09-20 14:10:12 EDT
 Omer Frenkel 2015-09-20 13:55:54 EDT
Target Release: 3.6.0 → 3.6.1
Target Milestone: ovirt-3.6.0-rc → ovirt-3.6.1

there is enough time until 3.6.0, it should be trivial change, no reason to defer and modify product behaviour, documentation and existing settings, require migration.
Comment 3 Michal Skrivanek 2015-09-25 03:16:11 EDT
(In reply to Alon Bar-Lev from comment #2)
>  Omer Frenkel 2015-09-20 13:55:54 EDT
> Target Release: 3.6.0 → 3.6.1
> Target Milestone: ovirt-3.6.0-rc → ovirt-3.6.1
> 
> there is enough time until 3.6.0, it should be trivial change, no reason to
> defer and modify product behaviour, documentation and existing settings,
> require migration.


We will not rush this change in between RC and GA. The patch is far from trivial. Retargeting to 3.6.1
Comment 4 Alon Bar-Lev 2015-09-25 03:24:47 EDT
(In reply to Michal Skrivanek from comment #3)
> (In reply to Alon Bar-Lev from comment #2)
> >  Omer Frenkel 2015-09-20 13:55:54 EDT
> > Target Release: 3.6.0 → 3.6.1
> > Target Milestone: ovirt-3.6.0-rc → ovirt-3.6.1
> > 
> > there is enough time until 3.6.0, it should be trivial change, no reason to
> > defer and modify product behaviour, documentation and existing settings,
> > require migration.
> 
> 
> We will not rush this change in between RC and GA. The patch is far from
> trivial. Retargeting to 3.6.1

I do not think you understand what z-stream is - it is not a play ground, although there are people who things that ovirt release is yet another beta given the users in "GA" name.

When this patch will be applied users that used vmconsole will have to modify settings to make it work, this is not something you do in z-stream.

We invested great effort to make it happen for the user sake.

Please remember that this feature has NEVER tested by QA before this so called "RC", in this case it should have been deferred to 4.0, but if not, it should begin QA cycle only from RC including all fixes required, especially these that are user visible.

The only QA that was done was by me and I am not QA.

Please retarget to 3.6.0 as it should.
Comment 5 Michal Skrivanek 2015-09-25 07:55:43 EDT
We would need a feedback from QE, they did finish testing some parts...but I don't know the exact status.
It may have been invalidated too by the recent changes. We need to stop rewriting stuff to give QE a chance to actually test something

If a change is not ready it should not be backported to RC and I'd rather push it out to the next release.
If it gets in before that then good, but it's not a change/feature which should block 3.6
 
Note there there are several big things planned to be introduced in zstream, e.g. EL 7.2, ppc64le support, spm removal.
Comment 6 Red Hat Bugzilla Rules Engine 2015-10-18 04:21:50 EDT
Fixed bug tickets must have version flags set prior to fixing them. Please set the correct version flags and move the bugs back to the previous status after this is corrected.
Comment 7 Red Hat Bugzilla Rules Engine 2015-10-19 06:53:36 EDT
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.
Comment 8 Yaniv Lavi 2015-10-29 08:34:48 EDT
In oVirt testing is done on single release by default. Therefore I'm removing the 4.0 flag. If you think this bug must be tested in 4.0 as well, please re-add the flag. Please note we might not have testing resources to handle the 4.0 clone.
Comment 9 Red Hat Bugzilla Rules Engine 2015-11-19 08:42:38 EST
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.
Comment 10 Nikolai Sednev 2015-11-25 01:14:28 EST
Please provide reproduction steps for this bug, so QA could verify.
Comment 11 Ravi Nori 2015-11-25 09:10:19 EST
1. Create a User with SUPER_USER / VM_OPERATOR or INSTANCE_OPERATOR permissions on DC or Cluster

2. Create a VM in the Cluster

3. Start the VM

4. List the user accessible running VMs using command
   
   ovirt-vmconsole-list.py consoles --entityid @USER_INTERNAL_ID@
   
   Where USER_INTERNAL_ID is the id of the user from database table users (can be admin user)
Comment 12 Nikolai Sednev 2015-12-07 11:10:08 EST
Works for me on these components:
rhevm-3.6.1.1-0.1.el6.noarch
ovirt-host-deploy-java-1.4.1-1.el6ev.noarch
ovirt-vmconsole-1.0.0-1.el6ev.noarch
ovirt-host-deploy-1.4.1-1.el6ev.noarch
ovirt-vmconsole-proxy-1.0.0-1.el6ev.noarch
ovirt-engine-extension-aaa-jdbc-1.0.4-1.el6ev.noarch

# ovirt-aaa-jdbc-tool user add black \
> --attribute=firstName=Black \
> --attribute=lastName=Blackovich \
> --attribute=email=black@blacksky.com
adding user black...
user added successfully

# ovirt-aaa-jdbc-tool user show black
-- User black(2fbb2bae-e9b1-450e-ac45-c53e74b388f8) --
Namespace: *
Name: black
ID: 2fbb2bae-e9b1-450e-ac45-c53e74b388f8
Display Name: 
Email: black@blacksky.com
First Name: Black
Last Name: Blackovich
Department: 
Title: 
Description: 
Account Disabled: false
Account Unlocked At: 1970-01-01 00:00:00Z
Account Valid From: 2015-12-07 15:40:50Z
Account Valid To: 2215-12-07 15:40:50Z
Account Without Password: false
Last successful Login At: 1970-01-01 00:00:00Z
Last unsuccessful Login At: 1970-01-01 00:00:00Z
Password Valid To: 1970-01-01 00:00:00Z

# ovirt-aaa-jdbc-tool user password-reset black
Password:
updating user black...
user updated successfully



# cat /etc/ovirt-engine/engine.conf.d/10-setup-database.conf
ENGINE_DB_HOST="localhost"
ENGINE_DB_PORT="5432"
ENGINE_DB_USER="engine"
ENGINE_DB_PASSWORD="8HVeFa9uGGn4CGg7LlOJqe"
ENGINE_DB_DATABASE="engine"
ENGINE_DB_SECURED="False"
ENGINE_DB_SECURED_VALIDATION="False"
ENGINE_DB_DRIVER="org.postgresql.Driver"
ENGINE_DB_URL="jdbc:postgresql://localhost:5432/engine?sslfactory=org.postgresql.ssl.NonValidatingFactory"

# su - postgres 
-bash-4.1$  psql -d engine
psql (8.4.20)
engine-# select * from users;
ERROR:  syntax error at or near "select"
LINE 2: select * from users;
        ^
engine=# select * from users;
               user_id                | name  |  surname   |     domain     | username | department |       email        | note | last_admin_check
_status |             external_id              |         _create_date          |         _update_date          | namespace 
--------------------------------------+-------+------------+----------------+----------+------------+--------------------+------+-----------------
--------+--------------------------------------+-------------------------------+-------------------------------+-----------
 00000018-0018-0018-0018-000000000279 | admin |            | internal-authz | admin    |            |                    |      | t               
        | 8cd95752-63a8-4738-a87d-89fc2617c5af | 2015-11-29 18:33:20.609721+02 | 2015-12-07 16:45:53.442793+02 | *
 973131f6-ba7e-4a37-974f-bf7139ee626a | Black | Blackovich | internal-authz | black    |            | black@blacksky.com |      | t               
        | 2fbb2bae-e9b1-450e-ac45-c53e74b388f8 | 2015-12-07 17:42:17.968475+02 | 2015-12-07 17:44:37.365973+02 | *
(2 rows)

engine=# \q
-bash-4.1$ exit


# /usr/libexec/ovirt-vmconsole-proxy-helper/ovirt-vmconsole-list.py consoles --entityid 00000018-0018-0018-0018-000000000279
{"content": "console_list", "consoles": [{"vmname": "vm1", "vmid": "2feb7c67-0875-4407-a64e-bd3d7a2120bd", "host": "alma04.qa.lab.tlv.redhat.com", "console": "2feb7c67-0875-4407-a64e-bd3d7a2120bd.sock", "vm": "vm1"}], "version": 1}
[root@nsednev-he-1 ~]# /usr/libexec/ovirt-vmconsole-proxy-helper/ovirt-vmconsole-list.py consoles --entityid 973131f6-ba7e-4a37-974f-bf7139ee626a
{"content": "console_list", "consoles": [{"vmname": "vm1", "vmid": "2feb7c67-0875-4407-a64e-bd3d7a2120bd", "host": "alma04.qa.lab.tlv.redhat.com", "console": "2feb7c67-0875-4407-a64e-bd3d7a2120bd.sock", "vm": "vm1"}], "version": 1}
Comment 13 Sandro Bonazzola 2015-12-16 07:20:06 EST
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.

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