Alexander Larsson

For listing the usb devices supported, maybe we can use the `--add-policy=SUBSYSTEM.KEY=VALUE` generic flatpak permissions. These are copied into the metadata file and will be accessible in /.flatpak-info for the...

I'm not 100% sure this is safe. Can we guarantee that there is no way a flatpak:ed app can create a request such when the portal calls statfs(/proc/$pid/root) it returns...

> > Can we guarantee that there is no way a flatpak:ed app can create a request such when the portal calls statfs(/proc/$pid/root) it returns EACCES. > > I'm not...

> > If people want to re-implement sandboxes and integrate with other systems like portals they need to do the work and integrate with it. I don't see any way...

> > I don't think you need setuid. For example, if you can trigger pid reuse by some other uid, then the /proc/$pid/root for that process might be inaccessible to...

> > If people want to re-implement sandboxes and integrate with other systems like portals they need to do the work and integrate with it. > > Does this scale?...

I've given some thought to the initial issue, and maybe things are not as grim as I initially though. Here is the basic setup: A process running in a flatpak...

> I thought more of defining standard way of connecting sandboxes with the x-d-p which could be used as fallback if checks for flatpak and snap failed. i.e reading metadata...

> Well no, the alternative is this mechanism. x-d-p or any other client could just query dbus for the app id. Any sandboxing mechanism only has to request a socket...

I think the problem might be with mount propagation. With pam_namespaces various processes will run in different namespaces, and if you mount something in one of them they need to...