<div dir="auto">IIRC portable services also work on plain directories. Could it maybe run on an OSTree checkout of the runtime and the app?<div dir="auto"><br></div><div dir="auto">Though there's still the part about the portable service sandbox being pretty different from bwrap... I think I wanted to try also added a static bwrap and modifying the services to redirect through that binary, though I never really got anywhere with that. <br><br><div data-smartmail="gmail_signature" dir="auto">--<br>Ryan (ライアン)<br>Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else<br><a href="https://refi64.com/">https://refi64.com/</a></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 15, 2018, 2:37 PM Christian Hergert <<a href="mailto:christian@hergert.me">christian@hergert.me</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/15/18 4:50 AM, Alexander Larsson wrote:<br>
> Flatpak is fundamentally based on the kernel support for unprivileged<br>
> user namespaces. This is the way we can launch a "container" sandbox<br>
> without ever needing to be root. (We alternatively also support doing<br>
> the same thing via a setuid bwrap helper, but that is immaterial for<br>
> this dicussion, so lets ignore that for now). We use the<br>
> PR_SET_NO_NEW_PRIVS prctl to guarantee this, and unless we do that,<br>
> the namespace operations will fail.<br>
<br>
Slightly off-topic, but on-topic enough to probably drive some direction<br>
of future features:<br>
<br>
I'd like to be able to ship Sysprof as a Flatpak (as well as not<br>
requiring Sysprof on the host from the Builder flatpak).<br>
<br>
Sysprof requires a systemd service which performs things like<br>
__NR_perf_event_open syscall and parsing /proc/kallsyms so that the UI<br>
process does not require elevated privileges. (All done via D-Bus fd<br>
passing and polkit authorization).<br>
<br>
I talked with Lennart at GUADEC about systemd portable services, and it<br>
sounded like that may be one avenue to explore. If we could have a way<br>
to register a systemd portable service from our Flatpak (even better if<br>
using the transient portable service feature for auto-cleanup?) then<br>
that could be one way to get elevated system access under an authorized<br>
scenario.<br>
<br>
What was rather tricky about it was that it requires passing a squashfs<br>
or tarball (or something of that nature) for the portable service.<br>
<br>
-- Christian<br>
_______________________________________________<br>
Flatpak mailing list<br>
<a href="mailto:Flatpak@lists.freedesktop.org" target="_blank" rel="noreferrer">Flatpak@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/flatpak" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/flatpak</a><br>
</blockquote></div>