-----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. 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/ But multi-X server environment still may be helpful in some cases, as you've noted above. > This patchset is tested in R3.2. There are two patches for > gui-daemon (the first is just to introduce a variable for > shm.id filename and the second is for the actual logic changes). I think the first patch alone (without the second one) will result in not compiling code. Because of this: +#define SHMID_FILENAME_LEN (sizeof(SHMID_FILENAME_PREFIX)) And SHMID_FILENAME_PREFIX is defined only in the second patch... > The gui-daemon changes in this patchset depends on 3c86bef963 > (Move /var/run/shm.id to /var/run/qubes/shm.id) which > is not in R3.2 (I cherrypicked it to R3.2 to make master > integration easier). The DISPLAY value is extracted from > /proc/self/cmdline for the shmoverride constructor which > I hope is an acceptable solution. I'm unsure what the code > should do if there is no DISPLAY found on the cmdline, > perhaps it should just bail out instead of returning :0 > as it does in the current changeset? I think the X server behaviour is to use ":0". For example if you try to start second X instance without specifying display, it will fail. So, I'm fine with this approach. Actually, lack of a method for extracting DISPLAY in shmoverride init call was the only reason why it wasn't implemented earlier. The idea of /proc/self/cmdline is ok. > There are two patches for core-admin. The second patch > for core-admin is not strictly necessary for R3.2 but > in order to make it easier to turn it master compatible > I added the second cludge change for testing in a more > master like codebase that supports migration from one > shm.id path to another. If requested, I can provide the > master based patch with the end result, however, testing > with master/R4.0 does not seem realistic for me at the > moment (is that required?). Change like this shouldn't go into stable release, as explained in github issue[1]. Unless you convince me that every case (like upgrading one package but not the other) is covered... 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. And one more thing: please sign your code. Details: https://www.qubes-os.org/doc/code-signing/ [1] https://github.com/QubesOS/qubes-issues/issues/2195 - -- 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 iQEcBAEBCAAGBQJYXKSdAAoJENuP0xzK19csCX0H/jEaRswMFvBddc0qhbUHkRTY K4KiXCKlOvUPh20ScQK0493NHfwaPfxdB5lLrXNV3r/N9KTcDxGFjhjptfpHUWAK p9rWYgBDyO3bT4sZd91Fwufy5c4bnaaw0ablHIFjsMBJsk6TICRcGDql2qZXR6YQ pFs1PEvA+yD2npbK+CBj8IVxFpdWxosIcx5oMgWrkLLQTbHD2L8tdhJ6VufIBhT/ 6ljyc4ztF1B2mJlSa1ABIInh2ljZs59vCNVJAJZmIkRqKZenqLpDAwa+nXLSmJ6D 788z8IiZMJDBo6fvaiszEmm0P6a8eTjvIaDcE05c0noa8CHA9Y9vRGh1cjcFWMY= =eM+M -----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/20161223041421.GN1239%40mail-itl. For more options, visit https://groups.google.com/d/optout.
