-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Dec 24, 2016 at 12:12:10AM +0200, Ilpo Järvinen wrote: > On Fri, 23 Dec 2016, Marek Marczykowski-Górecki wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On Fri, Dec 23, 2016 at 12:21:54AM +0200, Ilpo Järvinen wrote: > > > Hi all, > > > > > > This patchset enables shmoverride/qubes-guid daemon support > > > for running multiple X servers concurrently. It allows > > > having one (or some) appvm GUIs under X server(s) that > > > runs under other virtual console. The need for this has > > > come up at mailing list from time to time, e.g., opening > > > windows VM in a second virtual console [1] or an ability to > > > connect appvm directly to login screen by having a custom > > > xsession for that [2]. The custom xsession should also allow > > > limited multi-user support (however, Qubes RPC support for > > > that kind of usecase is currently very limited/does not > > > exits for more than one X server but denying cross-user > > > RPCs manually might be enough for start). > > > > > > If anyone has any thought / directions on how / what > > > should be implement for better Qubes RPC support for > > > the multi-user/X server case, please share. > > > > This alone is far from multi-user system. If you have access to dom0, > > you can execute any command in any VM. Even if you wouldn't see GUI of > > that VM. This isn't only about qrexec. For example you need access to > > libvirt daemon to start a VM and when you have it, you can access any VM > > configuration, console etc. There are a lot more things like this. > > All true. But this wasn't exactly what I was thinking though (I know > very well that dom0 access cannot be allowed)... What I meant was, > e.g., copy-paste (others too?) that need to be instanciated for each > user rather than having a global clipboard. > > With "limited multi-user support" I meant something along these lines: > A special "launchvm" that is the only thing that an ordinary (non-dom0) > user gets when logging in.
So, user interact only with "launchvm", right? How you envision to achieve this? In GUI domain concept it is achieved by attaching input/output devices to GUI domain instead of dom0. > The sole purpose of the launchvm is to > qvm-run the real applications in the actual user appvms (policy set to > allow this from launchvm for the user own appvms). That should probably > suffice for an initial version in the shared family computer use case > I mentioned earlier. Limited, but better than non-Qubes solutions for > sure. > > However, the "launchvm" concept is of course already quite close > to what management API aims to cover (especially if "launchvm" > extented beyond qvm-running). Yes, exactly. > > The proper solution for this is GUI domain, where local user > > will not have direct access to dom0 and only interact through set of > > qrexec services, subject to qrexec policy. Here is a WIP > > architecture: > > https://www.qubes-os.org/doc/mgmt-architecture/ > > It sounds very interesting. > > Maybe this is a stupid question: Is managing the physical machine > itself out-of-scope for this API (mainly to support shutdown/reboot > I guess)? You may be allowed to perform actions on dom0, like mgmt.vm.Shutdown. In extreme case, even qubes.VMShell - but then GUI domain isolation is somehow less meaningful. But on the other hand, when GUI will be moved to separate domain, there will be much less things to needed to be configured there. Those few things left will probably get some additional qrexec services for managing them. > > But don't worry - the tricky part (gui-daemon) is the same in > > R3.2 and R4.0, so testing it on R3.2 is ok. core-admin code is very > > different, but the patch is easy to apply manually there. And actually > > I'd reduce code duplication there - to have shm.id path constructed in > > one place, not three. > > Indeed, that would be much cleaner approach. I'll add that change to > the second version of the changeset. > > > And one more thing: please sign your code. Details: > > https://www.qubes-os.org/doc/code-signing/ > > Ok, I'll try (no prior experience gpg usage with email). If you like, you can also push git repository somewhere (github or else), with signed commits and/or signed tag at the top. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYXb0BAAoJENuP0xzK19cskPoH/1kqzEkYVImiyQHcpAdHsuA3 vYQT5W+1KCQRxtUSCD5R7JfyrnbVqENiSgYgn9SSze302ky9ojs6qlJO7NaX1ror skp/zaxALG93Wn8o8txY06so22neeY5cYtW5K+C8Z8kw4qBunQCE+6fhxgcaiwM+ nO/w/zOxwAyLBk/VJtUi3XwvudLa1TNnekMCRS84vDyr14OfjZQHifaJdN+U7tJd DsYFlG4f6I//eq6dYPF4/puZ8S7YYgGOsDG0nHJf3lhG0xZn2tujTrcpU3yOijJ3 Vtw0d7kG01XTqQLJgbF+Uh3IgJ0tcOxsYDnK7ZMuChao3zkWy3klzaqO3QGj9tg= =u+xK -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161224001040.GU1239%40mail-itl. For more options, visit https://groups.google.com/d/optout.
