On Mon, Jul 17, 2017 at 2:48 PM, Michael Stahl <mstahl@xxxxxxxxxx> wrote: > On 17.07.2017 19:26, Richard W.M. Jones wrote: >> On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote: >>> On 16.07.2017 12:54, Richard W.M. Jones wrote: >>>> On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote: >>>>> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote: >>>>>> >>>>>> If RPMs of the graphical application work fine now, what on earth is >>>>>> the point of forcing packagers to make Flatpaks? Sandboxing isn't one >>>>>> of them - as already explained, sandboxing is orthogonal to packaging. >>>>> >>>>> Huh? How would you get sandboxing without Flatpaks? Unless you are >>>>> proposing a different sandboxing technology. >>>> >>>> Things like libvirt-sandbox have been around for a really long time >>>> and don't require special packaging (in fact they work with any >>>> arbitrary command). >>> >>> reading between the lines of the fine documentation, there is no mention >>> of X11 or GUI applications, so i guess "arbitrary" is a bit of an >>> exaggeration? >> >> It seems like it's not mentioned in the docs, but it does work as in >> this example of running evince to view a suspect PDF file: >> >> https://honk.sigxcpu.org/con/More_sandboxing.html > > says: > > Note that the above example shares /tmp with the sandbox in order to > give it access to the X11 socket. A better isolation can probably be > achieved using xpra or xvnc but I haven't looked into this yet. > > so it doesn't actually sandbox very much, with access to the X11 socket > the app can keylog and inject shell commands into terminal windows as > much as it likes. > >> BTW libvirt sandbox allows either full-virt or container sandboxing. > > i'd hope if you don't use containers but full-virt it's going to use > something more secure, like SPICE or something to display the GUI? > > but i'd call virtualization a bit of a heavy-weight approach. > > ... there's more prior art, the SELinux "sandbox -X", which at least > starts a nested Xephyr for your convenience. > > http://danwalsh.livejournal.com/31146.html > http://danwalsh.livejournal.com/31247.html > > these have in common that they're generally not very user friendly: you > have to set up which files the program will have access to when you > start it; also copy/paste probably doesn't work between the nested X > server, which may or may not be a feature. > > FlatPak portals have the potential to be more user friendly since you > can use the application's normal file picker to open files and the > application only gets access to the file the user chooses. Portals themselves are orthogonal to the Flatpak distribution mechanism. They can be used with regular applications too. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
