[ovirt-devel] ovirt-guest-agent behavior on disconnect
David Mansfield
ovirt at dm.cobite.com
Fri Sep 25 17:40:44 UTC 2015
[cross-posted to devel at ovirt.org and spice-devel at lists.freedesktop.org]
Hi oVirt Devs,
I'm here from the spice-devel list where we were discussing some changes
to the behavior of the spice guest agent reacting to a user disconnect
(of the spice console).
Some information about how the ovirt-guest-agent works would be
informative if you can spare a minute.
The functionality being discussed is locking the user session in the VM
when the user disconnects from spice (either intentionally or
unintentionally).
Also, peripherally, how does oVirt ensure secure access by authorized
users of a VM and prevent "over-the-shoulder" snooping (spice graphics
session stealing) or other forms of information leak from a VM shared by
multiple users.
So here are some questions:
Can a VM be "shared" by multiple users in oVirt at all? Are there known
security issues that would make this a non-recommended or fundamentally
un-securable setup?
Does the oVirt agent lock the session on disconnect? Always /
unconditionally? If it's configurable, where does the configuration
reside - in the vm guest, on the vm host (/engine) or on the client?
Does the oVirt agent lock all sessions or the current active session?
How does it lock the sessions? I've looked at the code and it appears
'/usr/bin/loginctl lock-sessions' is being used on machines it's
provided on and something more complicated on older boxes. Does the
user have a way to customize this behavior? and if so, is it VM guest,
VM host or client configuration?
Does the agent lock linux consoles (VC1, VC2) "sessions" (e.g. with vlock?)
As I understand it, console access in ovirt is managed by setting a
temporary graphics password and then generating an .ini file which is
launched by remote-viewer. This password expires after a short period of
time. So is there a mechanism where access is denied if a user is
already connected or is this allowed?
Enough questions for now, sorry for the battering.
--
Thanks,
David Mansfield
Cobite, INC.
More information about the Devel
mailing list