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.

Sign up for GitHub

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

Jump to bottom

hooks for subscription management #31

Closed
cgwalters opened this issue Sep 30, 2014 · 5 comments
Closed

hooks for subscription management #31

cgwalters opened this issue Sep 30, 2014 · 5 comments

Comments

@cgwalters
Copy link
Member

Red Hat uses a tool called "subscription-manager" to allow access to content. Right now it has support for configuring the ostree remote with the new tls-ca-cert bits.

However, we need a bit more than that:

  1. Unconfigured state: if you type "atomic upgrade", but the system is unconfigured, and you need to run subman.

Rather than plugins, we could just have build-time hooks, something like: --with-unconfigured-tool=subscription-manager

  1. Handling of 403 due to expired certificates. We could add a config option to ostree like: tls-cert-tool=subscription-manager

This would just be a string that we would use when encountering errors, we could say:

error: Certificate rejected, use the external command "subscription-manager" to adjust configuration
@cgwalters
Copy link
Member Author

https://bugzilla.gnome.org/show_bug.cgi?id=737686

cgwalters added a commit to projectatomic/rpm-ostree-toolbox that referenced this issue Sep 30, 2014
@cgwalters
create-vm-disk: Support writing an unconfigured-state message
845e470 
See coreos/rpm-ostree#31
@james-antill
Copy link
Contributor

So the patch works by:

  1. Setting a flag in the deployment saying "this repo. is unconfigured and here is a message to give the user"
  2. Looking to see if that flag is set when the sysroot upgrader class is inited, and if so error with the configured message

...doesn't this mean it'll trigger on "rpm-ostree rebase"? And won't on "ostree pull"? Also means it can't work when the machine goes out of support and fetches get auth denied (not a big deal, just saying).

Implementation in gnome BZ patch looks fine, although I can't really comment well on the JS bit here.

@cgwalters
Copy link
Member Author

It will trigger for rebase, which is kind of annoying. I think maybe a new boolean for "ignore unsupported warning" would work?

Yeah, this isn't addressing the expired certificate case, merely the no certificate case.

cgwalters added a commit that referenced this issue Oct 2, 2014
@cgwalters
rebase: Make use of new upgrader API to ignore unconfigured state
01dd509 
"atomic rebase" is mostly a copy of "ostree admin switch", so let's
also pick up the changes in ostree admin switch for the new
unconfigured state flag.

This allows a user to "atomic rebase" on an unconfigured system.

Related: #31
@cgwalters cgwalters mentioned this issue Oct 2, 2014
Closed
cgwalters added a commit to ostreedev/ostree that referenced this issue Oct 3, 2014
@cgwalters
Add "unconfigured-state" concept to origin files
b3ad113 
Some operating systems may come with external tools for subscription
management that drive access to the content.  In that case, the origin
file may not be useful (for example, it could refer to an installer
ISO).

This patch will allow OS installers to inject that state, with a
useful error message, directing the system administrator to an
external tool.

See: coreos/rpm-ostree#31

https://bugzilla.gnome.org/show_bug.cgi?id=737686
cgwalters added a commit that referenced this issue Oct 4, 2014
@cgwalters
rebase: Make use of new upgrader API to ignore unconfigured state
8dab8d5 
"atomic rebase" is mostly a copy of "ostree admin switch", so let's
also pick up the changes in ostree admin switch for the new
unconfigured state flag.

This allows a user to "atomic rebase" on an unconfigured system.

Related: #31
@jlebon
Copy link
Member

jlebon commented Mar 15, 2017

The rebase case I think was fixed by #238. Do we want to keep this open for the expired cert case? This is probably a dup of #6.

@cgwalters cgwalters mentioned this issue Sep 21, 2017
Closed
@jlebon
Copy link
Member

jlebon commented Nov 26, 2020

This is no longer relevant.

@jlebon jlebon closed this as completed Nov 26, 2020
cgwalters referenced this issue in cgwalters/rpm-ostree Feb 2, 2021
@cgwalters
scripts: Fix a stack use-after-free
ebb0a40 
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive.  This of course would
have been caught by Rust...

```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
    #0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
    #1 0x7f92089da902  (/lib64/libglib-2.0.so.0+0x9f902)
    #2 0x7f92089de20f  (/lib64/libglib-2.0.so.0+0xa320f)
    #3 0x7f92089de52e  (/lib64/libglib-2.0.so.0+0xa352e)
    #4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
    #5 0x7f9208b7445f  (/lib64/libgio-2.0.so.0+0xab45f)
    #6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
    #7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
    #8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
    #9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
    #10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
    #11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
    #12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
    #13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
    #14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
    #15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
    #16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
    #17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
    #18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
    #19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
    #20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
    #21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
    #22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
    #23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
    #24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
    #25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
    #26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
    #27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
    #28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
    #29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
    #30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
    #31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)

Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
    #0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
cgwalters referenced this issue in cgwalters/rpm-ostree Feb 3, 2021
@cgwalters
scripts: Fix a stack use-after-free
184d641 
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive.  This of course would
have been caught by Rust...

```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
    #0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
    #1 0x7f92089da902  (/lib64/libglib-2.0.so.0+0x9f902)
    #2 0x7f92089de20f  (/lib64/libglib-2.0.so.0+0xa320f)
    #3 0x7f92089de52e  (/lib64/libglib-2.0.so.0+0xa352e)
    #4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
    #5 0x7f9208b7445f  (/lib64/libgio-2.0.so.0+0xab45f)
    #6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
    #7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
    #8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
    #9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
    #10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
    #11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
    #12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
    #13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
    #14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
    #15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
    #16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
    #17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
    #18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
    #19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
    #20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
    #21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
    #22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
    #23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
    #24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
    #25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
    #26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
    #27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
    #28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
    #29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
    #30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
    #31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)

Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
    #0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
openshift-merge-robot pushed a commit that referenced this issue Feb 3, 2021
@cgwalters @openshift-merge-robot
scripts: Fix a stack use-after-free
d616f73 
I think this changed in a recent refactoring; basically since
we're passing this stack-allocated value to the child spawn
function we need to keep it alive.  This of course would
have been caught by Rust...

```
==672376==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc290d9440 at pc 0x55c88c318946 bp 0x7ffc290d8b10 sp 0x7ffc290d8b08
    #0 0x55c88c318945 in script_child_setup src/libpriv/rpmostree-scripts.cxx:272
    #1 0x7f92089da902  (/lib64/libglib-2.0.so.0+0x9f902)
    #2 0x7f92089de20f  (/lib64/libglib-2.0.so.0+0xa320f)
    #3 0x7f92089de52e  (/lib64/libglib-2.0.so.0+0xa352e)
    #4 0x7f92089def02 in g_spawn_async_with_pipes (/lib64/libglib-2.0.so.0+0xa3f02)
    #5 0x7f9208b7445f  (/lib64/libgio-2.0.so.0+0xab45f)
    #6 0x7f9208b736d8 in g_subprocess_launcher_spawnv (/lib64/libgio-2.0.so.0+0xaa6d8)
    #7 0x55c88c3831b9 in rpmostree_bwrap_execute src/libpriv/rpmostree-bwrap.cxx:504
    #8 0x55c88c3836df in rpmostree_bwrap_run_captured src/libpriv/rpmostree-bwrap.cxx:450
    #9 0x55c88c31b5f1 in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:469
    #10 0x55c88c31ca9d in impl_run_rpm_script src/libpriv/rpmostree-scripts.cxx:588
    #11 0x55c88c31d22b in run_script src/libpriv/rpmostree-scripts.cxx:637
    #12 0x55c88c31d22b in rpmostree_script_run_sync src/libpriv/rpmostree-scripts.cxx:778
    #13 0x55c88c2ef830 in run_script_sync src/libpriv/rpmostree-core.cxx:3661
    #14 0x55c88c30afa6 in rpmostree_context_assemble src/libpriv/rpmostree-core.cxx:4422
    #15 0x55c88c34a9af in install_packages src/app/rpmostree-compose-builtin-tree.cxx:451
    #16 0x55c88c34c174 in impl_install_tree src/app/rpmostree-compose-builtin-tree.cxx:925
    #17 0x55c88c350f84 in rpmostree_compose_builtin_tree src/app/rpmostree-compose-builtin-tree.cxx:1421
    #18 0x55c88c276ec8 in rpmostree_handle_subcommand src/app/libmain.cxx:405
    #19 0x55c88c27827c in rpmostree_main_inner src/app/libmain.cxx:521
    #20 0x55c88c27827c in rpmostreecxx::rpmostree_main(rust::cxxbridge1::Slice<rust::cxxbridge1::Str const>) src/app/libmain.cxx:546
    #21 0x55c88c271c25 in operator() /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1257
    #22 0x55c88c271c25 in trycatch<rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda()>, rpmostreecxx::rpmostreecxx$cxxbridge1$rpmostree_main(rust::cxxbridge1::Slice<const rust::cxxbridge1::Str>)::<lambda(char const*)> > /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:997
    #23 0x55c88c271c25 in rpmostreecxx$cxxbridge1$rpmostree_main /var/srv/walters/src/github/coreos/rpm-ostree/rpmostree-cxxrs.cxx:1255
    #24 0x55c88c0468f7 in rpmostree_rust::ffi::rpmostree_main::hfedda48c684245ce rust/src/lib.rs:25
    #25 0x55c88c0468f7 in rpm_ostree::inner_main::hf078b99ca4b270aa rust/src/main.rs:9
    #26 0x55c88c0468f7 in rpm_ostree::main::hc0ca527cfaa3f556 rust/src/main.rs:28
    #27 0x55c88c046b22 in core::ops::function::FnOnce::call_once::h8567110dac55274e /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227
    #28 0x55c88c046b22 in std::sys_common::backtrace::__rust_begin_short_backtrace::h1c67f2f52d05cfa0 /var/home/walters/.rustup/toolchains/1.48-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137
    #29 0x55c88c045fd7 in main (/usr/bin/rpm-ostree+0xc9fd7)
    #30 0x7f92076091e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
    #31 0x55c88c045b9d in _start (/usr/bin/rpm-ostree+0xc9b9d)

Address 0x7ffc290d9440 is located in stack of thread T0 at offset 272 in frame
    #0 0x55c88c31a1af in rpmostree_run_script_in_bwrap_container src/libpriv/rpmostree-scripts.cxx:349
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@cgwalters @james-antill @jlebon