Bug 872723

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.

Sent  RFC patch series:
https://www.redhat.com/archives/virt-tools-list/2013-July/msg00083.html

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.

is there a support in .vv file? plugin?

(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.

good question, up to Scott, I'd say…is it ok to have a different level of functionality for plugin vs .vv?

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?

(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.

(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.

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