3:04 a.m.
On Sep 25, 2015, at 19:40 , David Mansfield <ovirt(a)dm.cobite.com> wrote:
[cross-posted to devel(a)ovirt.org and
spice-devel(a)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).
Hi David,
great, any enhancement is good! Vinzenz, please add more details to my guesses below:)
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?
normally no, there is a semi-supported hook to allow that with VNC (and even that is
slightly broken IIRC at the moment), but in general we do want so support that for
specific usecases
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?
it's oVirt management UI configuration, it changes the host's behavior on spice
disconnect per VM
Does the oVirt agent lock all sessions or the current active session?
just the active AFAIK
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?
connection is not allowed unless "strict user checking" disabled in UI
if it is disable or you use the same pwd then the previous session is terminated and
replaced (unless using that hook I mentioned).
But we try to treat the .vv file as a one time thing, there's delete_this_file=1 which
instructs virt-viewer to remove the file upon startup, so even when browser place them on
a shared drive they shouldn't be there for too long
What kind of changes do you have in mind on the SPICE side?
It would certainly make it easier for us as currently we kind of guess when to lock…we
receive multiple disconnecst(per channel) and don't really know what's going
on…having a direct support for this inside the spice server would be better. But it needs
to allow the flexibility of different actions except desktop lock (we have
"nothing", "shutdown", "logoff" I think). Perhaps a way how
to signal relevant information to vdsm is enough
Thanks,
michal
Enough questions for now, sorry for the battering.
--
Thanks,
David Mansfield
Cobite, INC.
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel