Bug 872723 - RFE: kioskmode option for virt-viewer
RFE: kioskmode option for virt-viewer
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer (Show other bugs)
6.3
All Linux
high Severity high
: rc
: ---
Assigned To: Marc-Andre Lureau
Virtualization Bugs
: FutureFeature
Depends On:
Blocks: 835616 960054 806907 1040926
  Show dependency treegraph
 
Reported: 2012-11-02 16:11 EDT by Patrick van der Bleek
Modified: 2016-04-26 09:39 EDT (History)
14 users (show)

See Also:
Fixed In Version: virt-viewer-0.6.0-1.el6
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1040926 (view as bug list)
Environment:
Last Closed: 2014-10-14 02:29:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
some wip (11.94 KB, patch)
2013-05-23 17:59 EDT, Marc-Andre Lureau
no flags Details | Diff

  None (edit)
Description Patrick van der Bleek 2012-11-02 16:11:12 EDT
Description of problem:
Currently virt-viewer always show menu options etc. Specific usecases require that the user is not able to change the behaviour of the virt-viewer window.
Being able to disable menu's from the CLI would help those usecases.

Version-Release number of selected component (if applicable):
6.3

How reproducible:
Always

Steps to Reproduce:
1. 
2.
3.
  
Actual results:
When starting virt-viewer menu options are always visible.

Expected results:
Ideally a set of CLI options should be available to disable or manipulate these options.

Additional info:
Comment 4 Marc-Andre Lureau 2013-05-23 17:59:22 EDT
Created attachment 752405 [details]
some wip

    WIP remote-viewer: Add simple kiosk mode option
    
    It opens in fullscreen and disable access to toolbar. I found several
    extra problems:
    
    1) how to keep the grabs? Currently, this is handled at widget level, and
     can escape easily. But we need a multi-window grab to allow drag and
     drop, or even to allow switching between display. I would say perhaps
     don't do anything else, but rely on configured desktop/wm (on Windows,
     extra work will be needed to prevent CAD and Win+L anyway, and VT
     switching on Linux).
    
    2) It should probably open blank windows on extra monitors?
    
    3) What about USB redirection dialog? Do only automated redirection?
      I guess custom-key menu sending isn't necessary.
    
    4) How do you quit? Never but over ssh or hard reboot?
    
    Perhaps only 2) is necessary. and 1) could be improved (although hardly
    perfectly) for a simple usage/setup.
Comment 7 Marc-Andre Lureau 2013-07-15 15:41:03 EDT
Sent  RFC patch series:
https://www.redhat.com/archives/virt-tools-list/2013-July/msg00083.html
Comment 10 tingting zheng 2014-06-09 03:29:48 EDT
Tested the bug with:
virt-viewer-0.6.0-5.el6.x86_64

Steps:
1.Check virt-viewer manual,option --kiosk has been added there:
# man virt-viewer
       -k, --kiosk
           Start in kiosk mode. In this mode, the application will start in fullscreen with minimal UI. It will
           prevent the user from quitting or performing any interaction outside of usage of the remote desktop
           session.

           Note that it can’t offer a complete secure solution by itself. Your kiosk system must have additional
           configuration and security settings to lock down the OS. In particular, you must configure or disable
           the window manager, limit the session capabilities, use some restart/watchdog mechanism, disable VT
           switching etc.

       --kiosk-quit <never|on-disconnect>
           By default, when kiosk mode is enabled, virt-viewer will remain open when the connection to the remote
           server is terminated. By setting kiosk-quit option to "on-disconnect" value, virt-viewer will quit
           instead. Please note that --reconnect takes precedence over this option, and will attempt to do a
           reconnection before it quits.

2.Test -k and --kiosk option.
# virt-viewer rhel6.5 -k 
# virt-viewer rhel6.5 --kiosk

Guest will be opened in fullscreen with minimal UI.

3.Test --kiosk-quit option.
3.1 Test --kiosk-quit never or default mode.
# virt-viewer rhel6.5 -k 
# virt-viewer rhel6.5 --kiosk --kiosk-quit never

When destroy the guest named rhel6.5,virt-viewer will keep and never quit.

3.2 Test --kiosk-quit on-disconnect mode.
# virt-viewer rhel6.5 --kiosk --kiosk-quit on-disconnect

When destroy the guest named rhel6.5,virt-viewer will quit.

3.3 Test --kiosk-quit with --reconnect option.
# virt-viewer rhel6.5 --kiosk --kiosk-quit on-disconnect --reconnect

When destroy the guest named rhel6.5,virt-viewer will not quit and wait for the guest to restart,so --reconnect takes precedence over --kiosk-quit.

4.Repeat step 2 and step 3.1,3.2 with remote-viewer,it works well.

Refer to the above comments,move the bug to VERIFIED.
Comment 11 Michal Skrivanek 2014-07-21 05:06:11 EDT
is there a support in .vv file? plugin?
Comment 12 Marc-Andre Lureau 2014-07-21 05:21:07 EDT
(In reply to Michal Skrivanek from comment #11)
> is there a support in .vv file? plugin?

Not yet. Any chance we only support this via vv file? (adding new controller message need changes in protocol, spice-gtk, spice-xpi, spicex, virt-viewer... great..) 

Adding to vv file should only be a patch in vv.
Comment 13 Michal Skrivanek 2014-07-21 05:38:42 EDT
good question, up to Scott, I'd say…is it ok to have a different level of functionality for plugin vs .vv?
Comment 14 Christophe Fergeau 2014-08-05 12:29:27 EDT
Note that the kiosk option has this in its documentation:
«
           Note that it can't offer a complete secure solution by itself. Your
           kiosk system must have additional configuration and security
           settings to lock down the OS. In particular, you must configure or
           disable the window manager, limit the session capabilities, use
           some restart/watchdog mechanism, disable VT switching etc.
»

Given these limitations and this need for additional configuration of other components, is this worth having this in the .vv file?
Comment 15 Scott Herold 2014-08-08 13:20:25 EDT
(In reply to Michal Skrivanek from comment #13)
> good question, up to Scott, I'd say…is it ok to have a different level of
> functionality for plugin vs .vv?

Michal - In this case, it is appropriate to have more functionality in the .vv file than plugins.  pm_ack+ on targeting .vv only.
Comment 16 Scott Herold 2014-08-08 13:29:03 EDT
(In reply to Christophe Fergeau from comment #14)
> Note that the kiosk option has this in its documentation:
> «
>            Note that it can't offer a complete secure solution by itself.
> Your
>            kiosk system must have additional configuration and security
>            settings to lock down the OS. In particular, you must configure or
>            disable the window manager, limit the session capabilities, use
>            some restart/watchdog mechanism, disable VT switching etc.
> »
> 
> Given these limitations and this need for additional configuration of other
> components, is this worth having this in the .vv file?

Kiosk modes are often used in very specific use cases.  I think that for these use cases specific setup requirements or limitations are justified.  Documentation points out these limitations so think we are good with the proposed solution.
Comment 17 errata-xmlrpc 2014-10-14 02:29:17 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1379.html

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