search

facebookincubator / xar

executable archive format
Other
1.57k stars 55 forks source link

Instead of invoking squashfuse_ll link with library #37

Open thedrow opened 5 years ago

thedrow commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

I think xar itself can have setuid no?

haampie commented 3 years ago

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

chipturner commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

haampie commented 3 years ago

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 commented 3 years ago

Let me make sure I understand the request:

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 commented 3 years ago

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 commented 3 years ago

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

haampie commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 ;).