Instead of invoking squashfuse_ll link with library

[thedrow]

The Ubuntu package contains the libsquashfuse_ll.so dynamic library. It is possible to use it instead of the executable itself for xarexec_fuse. We shouldn't wait for debian to package this binary to move forward.

[cooperlees]

I don't understand your wish here. xarexec_fuse needs to be setuid to enable mounting. How do you think we could get around that?

[thedrow]

I think xar itself can have setuid no?

[haampie]

@cooperlees what do you mean? appimage does this for instance

[chipturner]

Why is it desirable to give setuid bits to any of the xar tooling? One of the design intentions was to avoid setuid and rely on the more audited and understood fusermount binary to carry the setuid risk.

[haampie]

The libsquashfuse0 debian package just has a patch to rename main() to fuse_main() and generate a shared libsquashfuse_ll.so instead of an executable squashfuse_ll. AppImageKit is also using this patch for squashfuse. There is no need for setuid binaries (fusermount is the only setuid binary, and is part of libfuse, not squashfuse).

[thedrow]

@haampie Thank you! Would you mind collaborating on a PR? Let's talk.

@chipturner In order to use xar in production I need to be able to distribute xars with the least amount of friction possible.

[haampie]

I think for my usecase I'm more happy with appimages, although they still dlopen libfuse instead of baking it into the executable and do not support libfuse3 right now (also squashfuse requires an untagged commit for fuse3 support, yay)

[thedrow]

AppImages are nice for desktop applications. I don't intend to deploy a desktop application.

[haampie]

You can just do this:

$ mkdir myapp
$ echo '#!/bin/sh' > myapp/AppRun
$ echo 'echo hello' >> myapp/AppRun
$ chmod +x myapp/AppRun

$ mksquashfs myapp myapp.squashfs -root-owned -noappend

$ wget -qO myapp.app https://github.com/AppImage/AppImageKit/releases/download/12/runtime-x86_64
$ cat myapp.squashfs >> myapp.app
$ chmod +x myapp.app

$ ./myapp.app
hello

[chipturner]

Let me make sure I understand the request:

• Debian/Ubuntu ship with a patch that lets squashfuse be a library so fuse_main can be used instead of a standalone binary
• This lets other tools (AppImage?) simply invoke fuse_main rather than main so it simplifies packaging
• The patch (ref: https://github.com/vasi/squashfuse/issues/51) isn't super clear and doesn't seem to be standalone. Probably based on other diffs in the debian stack. Even then it isn't super clean and needs more help to also get a standalone executable.

So if someone wants to send a PR to squashfuse to (a) produce a library while (b) still producing a binary, we can then explore using it here. But we won't adopt a change here that depends on patches custom to some distributions (though getting it into squashfuse itself means the same APIs work and debian/ubuntu can drop their patch).

Sound reasonable?

[haampie]

Yeah, that's reasonable. To be honest I'm surprised this debian package even exists. Upstreaming those patches a few years ago would have been better.

The patches apply cleanly to the 103 version btw, but not to what has been master for a while and is now 104.

[thedrow]

Who owns the debian package? Maybe they can contribute the patches back?

[haampie]

I don't know the person who owns that package, but the patches were taken from the @TheAssassin's code in AppImageKit (pinging just in case you want to chime in: https://github.com/vasi/squashfuse/issues/51).

[haampie]

I've split squashfuse_ll into a lib and an executable, which is now merged (https://github.com/vasi/squashfuse/pull/59).

I'm also trying to improve building the whole set of libs squashfs + libfuse + zstd through spack, so that you dont' have to depend on your distro package manager for dev versions of any of these. I have two open pr's right now, but when they get merged soon (tm), you can build rather small binaries like this:

$ spack install squashfuse@master +min_size ~shared ~xz ~zlib ~lzo ~lz4 +zstd ^zstd ~shared build_type=MinSizeRel
...

$ du -sh /path/to/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/squashfuse-master-qlwzlkmrbef6lecotte74bkuoejsihm2/{bin,lib}/*
104K	/path/to/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/squashfuse-master-qlwzlkmrbef6lecotte74bkuoejsihm2/bin/squashfuse
112K	/path/to/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/squashfuse-master-qlwzlkmrbef6lecotte74bkuoejsihm2/bin/squashfuse_ll
60K	/path/to/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/squashfuse-master-qlwzlkmrbef6lecotte74bkuoejsihm2/lib/libsquashfuse.a
88K	/path/to/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/squashfuse-master-qlwzlkmrbef6lecotte74bkuoejsihm2/lib/libsquashfuse_ll.a
12K	/path/to/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/squashfuse-master-qlwzlkmrbef6lecotte74bkuoejsihm2/lib/pkgconfig

with minimal deps:

$ ldd /path/to/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/squashfuse-master-qlwzlkmrbef6lecotte74bkuoejsihm2/bin/squashfuse_ll 
	linux-vdso.so.1 (0x00007fffc39cf000)
	libfuse3.so.3 => /path/to/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/libfuse-3.10.2-sszn5y4diht4ohl2ck2oay4vkay3tvah/lib/libfuse3.so.3 (0x00007f527d046000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f527d006000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f527ce14000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f527ce0e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f527d0a5000)

[haampie]

@thedrow you might want to check out https://github.com/haampie/spack-batteries-included again, I've updated it to make the runtime executable static (statically linking libfuse, squashfuse, ...): the only requirement now is that you have fusermount or fusermount3 in your path. The runtime is 1MB, so that's the overhead -- I could maybe make it smaller by switching the libc provider. Licensing of the runtime executable is GPL because of libfuse, but I think that should not influence the licensing of whatever you ship in the squashfs file. If there is interest, I could move the runtime code into a standalone repository, although I don't necessarily aim to compete with AppImage & xar ;).