Re: [PATCH] img/app: fix running AppImages

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

Demi Marie Obenour <demiobenour@gmail.com> writes:

> On 12/8/25 16:11, Alyssa Ross wrote:
>> The non-root user that applications run as can't mount FUSE
>> filesystems.  I don't want to introduce setuid or an IPC service just
>> for running AppImages, although we could revisit if we find that
>> applications themselves rely on being able to mount FUSE filesystems.
>> For now, it'll be more efficient to use the in-kernel squashfs
>> implementation anyway.
>> 
>> We do need to set a few environment variables normally set by the
>> AppImage runtime, but as far as I can tell it doesn't do much more
>> than this that applications could rely on.
>> 
>> This only works for type 2 AppImages, but I expect that's just about
>> every AppImage nowadays, and if turns out not to be it shouldn't be
>> too hard to support type 1.
>> 
>> Fixes: 8bfcbf9 ("img/app: run applications as non-root")
>> Signed-off-by: Alyssa Ross <hi@alyssa.is>
>> ---
>>  img/app/Makefile                |  2 +-
>>  img/app/image/etc/s6-rc/app/run | 11 +++++++++--
>>  2 files changed, 10 insertions(+), 3 deletions(-)
>> 
>> diff --git a/img/app/Makefile b/img/app/Makefile
>> index ddfc8ef..7354f89 100644
>> --- a/img/app/Makefile
>> +++ b/img/app/Makefile
>> @@ -30,7 +30,7 @@ $(imgdir)/appvm/blk/root.img: ../../scripts/make-gpt.sh ../../scripts/sfdisk-fie
>>  	    build/rootfs.erofs:root:5460386f-2203-4911-8694-91400125c604:root
>>  	mv $@.tmp $@
>>  
>> -DIRS = dev home/user run proc sys tmp \
>> +DIRS = dev home/user run mnt proc sys tmp \
>>  	etc/s6-linux-init/run-image/pipewire \
>>  	etc/s6-linux-init/run-image/service \
>>  	etc/s6-linux-init/run-image/user \
>> diff --git a/img/app/image/etc/s6-rc/app/run b/img/app/image/etc/s6-rc/app/run
>> index e05d4fe..e691a63 100755
>> --- a/img/app/image/etc/s6-rc/app/run
>> +++ b/img/app/image/etc/s6-rc/app/run
>> @@ -14,10 +14,17 @@ foreground {
>>    withstdinas -E type
>>    case $type {
>>      appimage {
>> -      if { modprobe fuse }
>> +      if { modprobe loop }
>> +      if {
>> +        backtick -E offset { /run/virtiofs/virtiofs0/config/run --appimage-offset }
>> +        mount -o offset=${offset} /run/virtiofs/virtiofs0/config/run /mnt
>> +      }
>>        s6-setuidgid user
>> +      export APPIMAGE /run/virtiofs/virtiofs0/config/run
>> +      export APPDIR /mnt
>> +      export ARGV0 /mnt/AppRun
>>        export LD_LIBRARY_PATH /lib64
>> -      /run/virtiofs/virtiofs0/config/run
>> +      /mnt/AppRun
>>      }
>>      flatpak {
>>        s6-envdir -fnL /run/virtiofs/virtiofs0/config/params
>> 
>> base-commit: 5104fa720ce8b00612c5487fc47124fbf99e58c6
>
> The kernel SquashFS implementation probably isn't hardened against
> malicious inputs.  I'd stick with the setuid binary for now, or write
> an IPC service.  Unlike the host, the guest doesn't have no_new_privs
> as far as I know.  Another option is to run the app as user namespace
> root with CAP_SYS_ADMIN (but not CAP_NET_ADMIN or other capabilities).

Since the only purpose of an application VM is to run an application,
I'm not very worried about the kernel squashfs implementation.  We do
not trust guest kernels anyway.  (The purpose of not running everything
as root here is to make the system easier to understand and maintain,
and to present a more normal environment for applications.)

Setuid isn't as easy as that — we'd need to do something like NixOS's
wrappers mechanism to even have setuid binaries available.  We could
alternatively possibly copy a static binary to a tmpfs, but in these
particular circumstances I think going through fuse is worse than
letting the kernel do it anyway.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]