Panic on package build failure. about rua

[vn971]

I see that it's in rua::aur:fresh_download then.
I'll check this method, as well as other usages of unwrap that I have.
Big thanks with the report! I'll try to come back on it very soon or during next day.

[vn971]

@c-edw Apparently, the only way to run bubblewrap/rua inside docker is to use --privileged=true as a docker argument. I can't support that solution though, I don't think it's in any way secure..

So what I am in fact going to propose, if you want to play with RUA, is to just run it from a separate user in your main OS. This way your normal Linux kernel will still keep the user in its place, while all of RUA functionality will work. Packages will be additionally build inside a (pretty restrictive) bwrap jail, which is pretty much secure. As secure as you can get with the Linux kernel, I'd personally say.

Anyway, I don't think I really have any options to defeat the "bubblewrap inside docker" problem...

[cedws]

Does rua support package building without the bubblewrap jail? Maybe you could somehow detect if being run inside a Docker container?

Unfortunately I don't run Arch on my root system, and I was using the container to test various AUR helpers.

[vn971]

@c-edw Automatic disabling of security properties is something that I'd rather avoid, even if program thinks it runs inside docker. An explicit argument is possible though. I'll take some time on this.

[vn971]

@c-edw Do you have backtrace at all, or is it just unhelpful? If you're compiling via AUR, you need to uncomment options+=(!strip), because otherwise makepkg strips out all debug symbols.

[vn971]

@c-edw yes, panicking is indeed not a nice thing to have. I need to make an iteration of cleaning them up again, probably.

By the way, have you installed the dependencies?: https://github.com/vn971/rua#install-dependencies

[cedws]

The first time, I followed Install (the AUR way), which lead to this issue. I've just tried Install (the Rust way) but get an immediate panic when trying to install something. I'm the root user in a Docker container, if that matters.

thread 'main' panicked at 'Failed to git-clone repository wlroots-git: Os { code: 2, kind: NotFound, message: "No such file or directory" }', libcore/result.rs:1009:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:211
   2: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:227
             at libstd/panicking.rs:477
   3: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:391
   4: rust_begin_unwind
             at libstd/panicking.rs:326
   5: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   6: core::result::unwrap_failed
   7: rua::aur::fresh_download
   8: rua::wrapped::prefetch_aur
   9: rua::wrapped::install
  10: rua::main
  11: std::rt::lang_start::{{closure}}
  12: main
  13: __libc_start_main
  14: _start

[cedws]

I have installed the dependencies also.

[vn971]

@c-edw it actually seems as though git is unavailable inside your OS. Could that be true? I was pretty sure git is part of the base-devel package, but maybe it's not?

( If it's not, please install git and say if it fixes the problem? )

[cedws]

Installing git got me past the immediate panic. I will continue testing.

[cedws]

I've encountered the panic again after installing some packages.

Enter S to `sudo` install it, or install manually and press M when done. M
bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'.
thread 'main' panicked at 'Failed to build package', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/rua-0.9.10/src/wrapped.rs:61:2
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:211
   2: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:227
             at libstd/panicking.rs:477
   3: std::panicking::begin_panic
   4: rua::wrapped::build_directory
   5: rua::wrapped::install
   6: rua::main
   7: std::rt::lang_start::{{closure}}
   8: main
   9: __libc_start_main
  10: _start

[vn971]

@c-edw This one is from bwrap -- the security sandbox the project uses: https://github.com/projectatomic/bubblewrap
I wonder if you'll have the error while running from non-root. This needs some thinking-upon. The issue itself is basically outside of RUA totally.

On the other hand, people say that running bubblewrap inside docker works at least partly: containers/bubblewrap#284
so there probably is something we can do.

[cedws]

I have tried installing with rua under an unprivileged user, which gives a different error:

bwrap: capset failed: Operation not permitted
thread 'main' panicked at 'Failed to build package', /home/cedwards/.cargo/registry/src/github.com-1ecc6299db9ec823/rua-0.9.10/src/wrapped.rs:61:2
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
             at libstd/panicking.rs:211
   2: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:227
             at libstd/panicking.rs:477
   3: std::panicking::begin_panic
   4: rua::wrapped::build_directory
   5: rua::wrapped::install
   6: rua::main
   7: std::rt::lang_start::{{closure}}
   8: main
   9: __libc_start_main
  10: _start

This is when running with RUST_BACKTRACE=1 .cargo/bin/rua install wlroots-git. If I run it with sudo, it gives the same error as when it was run under root.

If you'd like, I can report this on bubblewrap.

[vn971]

@c-edw Apparently "bubblewrap" needs some rights to prepare the jail, which docker lacks by default. This issue describes the very same problem I think: flatpak/flatpak#1326

[vn971]

I've installed docker with an Arch image, the problem is totally reproducible.
The easiest way to repro the issue is to just invoke bubblewrap directly:
bwrap --dev-bind / / bash

[cedws]

But helpers such as yay don't build inside a jail, right? Of course, the security feature is nice, but it's not a disaster if disabled.

[vn971]

Closing in favor of #8. Thanks for raising and all the feedback! This is not the highest-priority feature at the moment, though, unfortunately. We'll see how it goes in the future. If you want, you can provide a PR, presuming the following holds:

• the CLI override should work for both the "jailbuild" and "install" commands
• the CLI override does not have a very short form, only somewhat longer (kinda discouraging overuse)
• the CLI override should work only if bwrap --dev-bind / / true fails to run, basically meaning bwrap fails.
• if/when jail is disabled, nice -n19 ionice -c idle can instead be used as a wrapper (for example).

The last restriction can be lifted if there's a serious argument against it, but otherwise let it stay.

[vn971]

For the record, rua will now fail-fast if it sees that the security jail cannot be launched. It will also explain the situation explicitly.

Commands that do not require the jail, like rua search, rua info, rua upgrade --printonly, can be run just fine.

[cedws]

Thanks, I will take another look at this project when I get the opportunity.

[gwpl]

How to use CLI override described in #6 (comment) ?
I can't find examples in README.md nor docs/ or rua --help or rua intall --help.