Re: [Spice-devel] [ovirt-devel] ovirt-guest-agent behavior on disconnect

2015-09-30 Thread Michal Skrivanek 

On Sep 25, 2015, at 19:40 , David Mansfield  wrote:

> [cross-posted to de...@ovirt.org and spice-devel@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
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST

2013-06-24 Thread Michal Skrivanek 

On Jun 20, 2013, at 14:27 , Itamar Heim ih...@redhat.com wrote:

 On 06/20/2013 03:13 PM, Tomas Jelinek wrote:
 
 
 - Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Christophe Fergeau cferg...@redhat.com
 Cc: Tomas Jelinek tjeli...@redhat.com, engine-devel 
 engine-de...@ovirt.org,
 spice-devel@lists.freedesktop.org, Marc-André Lureau mlur...@redhat.com
 Sent: Thursday, June 20, 2013 1:09:21 PM
 Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
 
 On 06/20/2013 02:07 PM, Christophe Fergeau wrote:
 Hey Itamar,
 
 On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
 On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
 Hi all,
 
 for the non plugin invocation of the console
 (http://www.ovirt.org/Features/Non_plugin_console_invocation) the
 dynamicMenu property is not usable to enrich the SPICE client menu.
 
 This feature is about requesting this menu using oVirt's REST API and
 than calling it back once some item from this menu has been selected.
 
 The oVirt's feature page with specific details:
 http://www.ovirt.org/Features/Foreign_Menu_Using_REST
 
 Any comments are more than welcomed.
 
 Why are we putting the logic of the menu into the REST API?
 can't the menu be builded by client based on getting the list of
 ISO's and current CD?
 
 The client needs a way to get the list of available ISOs in order to build
 the menu, as well as a way to let the engine know when the user clicked on
 an ISO in the menu. One way of doing that is to have the menu stuff exposed
 in the REST API. Another way would be to expose the list of ISOs in the
 REST API (I'd have a slight preference for that I think).
 
 that's my preference as well, and the REST API should already do that today:
 - get list of ISOs of available in a DC (the one the VM is in)
 - ability to change the CD of the VM
 Well, and what about the stop/suspend VM for example, what we have in the 
 menu today?
 
 supported as well.
 
 Also this should be something that the client decide to have or not have?
 
 I think the client should decide on the features relevant to the client.
 
 
 
 Or do you have anything in mind for the client to get the list of ISOs
 available to the engine?
 
 my preference is to provide the data, not the semantics of the menu.
 We should clarify something here. There are two possibilities who should be 
 responsible for deciding
 what should the foreign menu contain and also what to do if it the item is 
 selected:
 1: the client - e.g. we will not provide any support for the menu in REST 
 because the client reads what needs
and knows how to call the oVirt back
 
 2: the server side - e.g. we will provide in REST side the menu structure 
 with the description what to do if something is
selected
 
 Both have some advantages and disadvantages but we need to clarify which way 
 to go. So, who is the one responsible to decide
 what is in the foreign menu (now or in the future) and how to react if 
 something is selected? Client or engine?
 
 my preference is the client will decide this, as there are various clients to 
 the REST API, and each should decide which features are important for them.

I would agree as long as it is not hardcoded and can be change in some config 
file easily. We shouldn't wait for next RHEL release to do a little 
modification if possible.
I think owning the menu in some form on RHEV-M side has an advantage of 
delivery synchronization.


 
 
 iiuc, we are on the same page.
 
 
 Christophe
 
 
 
 
 ___
 Engine-devel mailing list
 engine-de...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Engine-devel] SPICE Foreign Menu Using REST

2013-06-24 Thread Michal Skrivanek 

On Jun 24, 2013, at 10:08 , Itamar Heim ih...@redhat.com wrote:

 On 06/24/2013 11:02 AM, Michal Skrivanek wrote:
 
 On Jun 20, 2013, at 14:27 , Itamar Heim ih...@redhat.com wrote:
 
 On 06/20/2013 03:13 PM, Tomas Jelinek wrote:
 
 
 - Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Christophe Fergeau cferg...@redhat.com
 Cc: Tomas Jelinek tjeli...@redhat.com, engine-devel 
 engine-de...@ovirt.org,
 spice-devel@lists.freedesktop.org, Marc-André Lureau 
 mlur...@redhat.com
 Sent: Thursday, June 20, 2013 1:09:21 PM
 Subject: Re: [Engine-devel] [Spice-devel] SPICE Foreign Menu Using REST
 
 On 06/20/2013 02:07 PM, Christophe Fergeau wrote:
 Hey Itamar,
 
 On Wed, Jun 19, 2013 at 06:00:47PM +0300, Itamar Heim wrote:
 On 06/19/2013 04:33 PM, Tomas Jelinek wrote:
 Hi all,
 
 for the non plugin invocation of the console
 (http://www.ovirt.org/Features/Non_plugin_console_invocation) the
 dynamicMenu property is not usable to enrich the SPICE client menu.
 
 This feature is about requesting this menu using oVirt's REST API and
 than calling it back once some item from this menu has been selected.
 
 The oVirt's feature page with specific details:
 http://www.ovirt.org/Features/Foreign_Menu_Using_REST
 
 Any comments are more than welcomed.
 
 Why are we putting the logic of the menu into the REST API?
 can't the menu be builded by client based on getting the list of
 ISO's and current CD?
 
 The client needs a way to get the list of available ISOs in order to 
 build
 the menu, as well as a way to let the engine know when the user clicked 
 on
 an ISO in the menu. One way of doing that is to have the menu stuff 
 exposed
 in the REST API. Another way would be to expose the list of ISOs in the
 REST API (I'd have a slight preference for that I think).
 
 that's my preference as well, and the REST API should already do that 
 today:
 - get list of ISOs of available in a DC (the one the VM is in)
 - ability to change the CD of the VM
 Well, and what about the stop/suspend VM for example, what we have in the 
 menu today?
 
 supported as well.
 
 Also this should be something that the client decide to have or not have?
 
 I think the client should decide on the features relevant to the client.
 
 
 
 Or do you have anything in mind for the client to get the list of ISOs
 available to the engine?
 
 my preference is to provide the data, not the semantics of the menu.
 We should clarify something here. There are two possibilities who should 
 be responsible for deciding
 what should the foreign menu contain and also what to do if it the item is 
 selected:
 1: the client - e.g. we will not provide any support for the menu in REST 
 because the client reads what needs
and knows how to call the oVirt back
 
 2: the server side - e.g. we will provide in REST side the menu structure 
 with the description what to do if something is
selected
 
 Both have some advantages and disadvantages but we need to clarify which 
 way to go. So, who is the one responsible to decide
 what is in the foreign menu (now or in the future) and how to react if 
 something is selected? Client or engine?
 
 my preference is the client will decide this, as there are various clients 
 to the REST API, and each should decide which features are important for 
 them.
 
 I would agree as long as it is not hardcoded and can be change in some 
 config file easily. We shouldn't wait for next RHEL release to do a little 
 modification if possible.
 I think owning the menu in some form on RHEV-M side has an advantage of 
 delivery synchronization.
 
 
 this forces you to maintain backward compatibility in the Menu API, the 
 client to handle ignoring new features/items in the menu they don't support 
 yet, etc.
 while the *data* which is the important part is already in the stable, 
 backward compatible, API.

i don't think it would be needed. We don't really need much features on spice 
client side except for displaying and invoking a generic REST call. Items 
support is based on Engine side if the menu is supplied by Engine side.


 
 
 
 
 iiuc, we are on the same page.
 
 
 Christophe
 
 
 
 
 ___
 Engine-devel mailing list
 engine-de...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/engine-devel
 
 

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [Users] [oVirt 3.1] Spice USB support

2012-10-25 Thread Michal Skrivanek 

On 9 Oct 2012, at 15:21, Andres Gonzalez wrote:

 On Tue, Oct 9, 2012 at 4:00 AM, Itamar Heim ih...@redhat.com wrote:
 On 10/08/2012 04:34 PM, Andres Gonzalez wrote:
 On Mon, Oct 8, 2012 at 12:02 PM, Itamar Heim ih...@redhat.com
 mailto:ih...@redhat.com wrote:
 
 On 10/08/2012 03:29 PM, Andres Gonzalez wrote:
 
 On Mon, Oct 8, 2012 at 4:02 AM, Itamar Heim ih...@redhat.com
 mailto:ih...@redhat.com
 mailto:ih...@redhat.com mailto:ih...@redhat.com wrote:
 
  On 10/08/2012 04:29 AM, Andres Gonzalez wrote:
 
  Hi !!
 
  I have a Windows 7 VM with spice protocol with usb
 redirection
  enabled
  but I cannot access to e.g. to a pendrive.
  It's already supported this feature ?
 
 
  (adding spice-devel)
  please note only the native spice usb mode is supported
 (legacy is not).
  which client?
  which guest?
  which ovirt version?
 
 
 
 The mode is set yo legacy, I tried to switch to native but the VM
 doesn't starts, and show the following error: VM Win7 is down. Exit
 message: internal error Process exited while reading console log
 output:
 qemu-kvm: -device piix3-usb-uhci,id=usb,bus=pci.__0,addr=0x1.0x2:
 
 Duplicate ID 'usb' for device .
 
 
 legacy isn't relevant to ovirt (its legacy...).
 the native error was already fixed.
 which versions of ovirt engine are you using?
 
 
 - oVirt version: oVirt Engine Version:3.1.0-3.19.el6
 
 
 
 - client:
 RHEV-Agent 3.0.10
 RHEV-Block 3.0.8
 RHEV-Network 3.0.6
 RHEV-Serial 3.0.5
 RHEV-Spice 3.0.5
 RHEV-Spice-Agent 3.0.4
 RHEV-Tools 3.0.37
 RHEV-USB 3.0.8
 
 
 wait, these are rhev, not ovirt?
 (rhev does have legacy usb mode)
 
 
 I downloaded those package from the Internet, what are the guest
 packages supposed to be installed ?
 
 1. not sure where you downloaded them from - they are not re-distributable in 
 their binary form afair.
 
 2. these are the guest tools, you would need the client tools as well, which 
 in legacy mode require some proprietary 3rdparty software (hence it is legacy)
 
 3. i recommend trying the new native mode (i.e, which spice client supports, 
 open source based).
 
 3. to try the new native mode, I should upgrade oVirt version ?
Those RHEV packages should be removed
The latest 3.1 should work. 

Thanks,
michal

 
 
 
 -- 
 AGD
 ___
 Users mailing list
 us...@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel