AppImages with "everything" from up-to-date systems (using makeaoi)?

[Lutz Vieweg]

On 07/10/2017 01:17 AM, Dirk Hohndel wrote:
>> Arch Linux does ship Qt 5.9.1 currently.
>
> Yes, but we (i.e., I) don't build binaries for Arch. One of our developers
> does this (and right now I'm spacing on who it is - how embarrassing).

https://www.archlinux.org/packages/community-staging/x86_64/subsurface/
says it is Gaetan Bisson. And the latest build date is 2017-07-09 03:50 UTC -
that sounds pretty recent.

>> it does not yet support ioctl() stuff like subsurface needs to do
>> on device files connecting to dive computer hardware.
>
> Ah, that's a bummer.

Yes. So far I see two ideas how to tackle that:

a) extend the "fake devices via regular files" approach by passing along
    ioctl() commands.
    Seems like a moderate amount of effort, but success is of course unclear
    until tried.

b) extend unionfs-fuse by CUSE support, trying to pass through the
    system devices as user space devices.
    Seems like a lot of effort - unionfs-fuse uses libfuse, and libfuse
    does not seem to support CUSE, plus there are only very few examples
    of other software using CUSE at all, so this territory might be
    full of obstacles no one ever encountered.

> I certainly think this sounds extremely interesting. But I worry about things
> like BT, BLE, device access.

It might be that BT communication is currently based on
"being able to talk to some daemon that is expected to
run on the system and do magic things talking to devices" -
and while it would be simple to pack such daemons, too,
it might be problematic to run them on a target system
as they could collide with some already running daemons
that allocate the same system resources.

However, this problem exists in a similar form also for
"conventional" AppImages built on "old" systems: If the
"old" system does not run a fancy up-to-date bluetooth
service, an AppImage not bringing it along will also not
be able to talk to BT devices.

I personally do not own a BT or BLE based dive computer,
which would make it more difficult for me to try.
But if the device emulation thing works, it would probably
worth trying whether BT/BLE can also be made to work.

>> BTW: The subsurface-x86_64.AppImage I created on Arch has a size of
>> 150 MB
> Yikes. That is big.

In comparison to a package only containing subsurface, sure,
but not compared to the added sizes of subsurface, marble, qt5,
grantlee etc. :-)

> Obviously one could build a version with that flag disabled. I assume
> the app drops privileges, correct?

The app never has special privileges, so there's nothing to drop.

Sure, if you run "unshare -r whoami" it tells you "root",
but try "unshare -r bash" and then "ls /root/" or
"touch /tmp/somefile" and you will see that in the namespace
of the host, things are still done as the normal user who ran "unshare".

subsurface could look into /proc/self/uid_map, and only warn about
"being root" if that file does not exist or still contains the default mapping
"0 0 4294967295".

Regards,

Lutz Vieweg