Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic on package build failure. #6

Closed
cedws opened this issue Nov 27, 2018 · 20 comments
Closed

Panic on package build failure. #6

cedws opened this issue Nov 27, 2018 · 20 comments

Comments

@cedws
Copy link
Contributor

cedws commented Nov 27, 2018

I am trying to install some packages and am getting a panic on src/wrapped.rs:61:2. The backtrace is pretty unhelpful, but it looks like the command that was being executed didn't return 0.

Ideally this shouldn't panic, but should just print a warning or error.

@vn971
Copy link
Owner

vn971 commented Nov 27, 2018

@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
Copy link
Owner

vn971 commented Nov 27, 2018

@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
Copy link
Contributor Author

cedws commented Nov 27, 2018

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
Copy link
Contributor Author

cedws commented Nov 27, 2018

I have installed the dependencies also.

@vn971
Copy link
Owner

vn971 commented Nov 27, 2018

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
Copy link
Owner

vn971 commented Nov 27, 2018

@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
Copy link
Contributor Author

cedws commented Nov 27, 2018

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

@cedws
Copy link
Contributor Author

cedws commented Nov 27, 2018

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.aaakk.us.kg-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
Copy link
Owner

vn971 commented Nov 27, 2018

@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
Copy link
Contributor Author

cedws commented Nov 27, 2018

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.aaakk.us.kg-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
Copy link
Owner

vn971 commented Nov 27, 2018

@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
Copy link
Owner

vn971 commented Nov 27, 2018

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

@vn971
Copy link
Owner

vn971 commented Nov 27, 2018

@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
Copy link
Contributor Author

cedws commented Nov 27, 2018

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
Copy link
Owner

vn971 commented Nov 27, 2018

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

@cedws
Copy link
Contributor Author

cedws commented Nov 27, 2018

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
Copy link
Owner

vn971 commented Nov 29, 2018

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 vn971 closed this as completed Nov 29, 2018
@vn971
Copy link
Owner

vn971 commented Nov 20, 2019

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
Copy link
Contributor Author

cedws commented Nov 22, 2019

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

@gwpl
Copy link

gwpl commented Oct 24, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants