cli: add install print-configuration --root-dir
#1825
Conversation
When `install print-configuration` is run some options (notably the kargs) are currently filtered out. This makes sense because in general `bootc install to-filesystem` takes care of them. However with the recent work in image-builder/osbuild to use bootc containers directly as inputs to build ISOs [0],[1] we would like to get access to the kernel args too because when constructing a bootable ISO we also want to add the bootc container kargs. [0] https://github.com/orgs/osbuild/discussions/45 [1] osbuild/images#1906
cgwalters
left a comment
cgwalters
left a comment
There was a problem hiding this comment.
Sure, seems fine to me. That said:
We would like to only inspect a container image with
{bootc,}image-builder and not actually run the container. One reason is (too much?) paranoia, i.e. we want to eventually
support bootc containers coming from the users that get passed
into the service and not having to run anything on the container
initially to generate the osbuild manifest minimizes the risk.
And in this model the bootc binary being invoked would come from the bootc-image-builder container, and not the users' container so would be theoretically more predictable? I guess but...I think doing this via the equivalent of RUN --network=none bootc install print-configuration would constrain unpredictability enough too.
|
[..]
I will talk to the rest of the team about this, honestly I'm not sure myself, I would like to minimize the attack surface in the service as much as possible and and ideally run no-user provided code at the manifest generation time (where we are much less isolated than at build time). But maybe I'm just overly paranoid, this is run inside containers and as you pointed out, there are ways like "network=none" to heavily restrict what the container can do. Therefore I leave this as "draft" until we discussed this internally again. But thanks a lot for your excellent review, even though its a tiny amount of code I enjoyed the codebase (and rust). |
mvo5
force-pushed
the
print-config-rootdir
branch
from
a562174 to
bf04398
Compare
We would like to only inspect a container image with
{bootc,}image-builder and not actually run the container.
One reason is (too much?) paranoia, i.e. we want to eventually
support bootc containers coming from the users that get passed
into the service and not having to run anything on the container
initially to generate the osbuild manifest minimizes the risk.
So to still get the require parameters like preferred rootfs
or kargs we would like to run our own bootc and then pass
```
bootc install print-configuration --root-dir /path/to/mounted/cnt
```
to generate the manifest. The actual build will still run
the `boots install to-filesystem` from the container. But that
step happens in an isolated instance that is destroyed after
each build (we already do this for package based image builds
as users can also inject custom content/rpms here).
This PR implements this new "--root-dir" option.
It also tweaks print_configuration to make it easier to
test. With that we could drop parts of the tests for
PR#1820 from the container.rs and move them in here.
Signed-off-by: Michael Vogt <michael.vogt@gmail.com>
mvo5
force-pushed
the
print-config-rootdir
branch
from
bf04398 to
c78fa5c
Compare
cgwalters
left a comment
cgwalters
left a comment
There was a problem hiding this comment.
LGTM but needs a rebase and DCO
|
|
||
| /// Set an alternative rootdir | ||
| #[clap(long, default_value = "/")] | ||
| pub(crate) root_dir: Option<String>, |
There was a problem hiding this comment.
To have default_value work just drop the Option
2 participants
[draft as this is potentially controversial, also build on top f #1820 mostly to avoid conflicts]
We would like to only inspect a container image with
{bootc,}image-builder and not actually run the container.
One reason is (too much?) paranoia, i.e. we want to eventually
support bootc containers coming from the users that get passed
into the service and not having to run anything on the container
initially to generate the osbuild manifest minimizes the risk.
So to still get the require parameters like preferred rootfs
or kargs we would like to run our own bootc and then pass
to generate the manifest. The actual build will still run
the
boots install to-filesystemfrom the container. But thatstep happens in an isolated instance that is destroyed after
each build (we already do this for package based image builds
as users can also inject custom content/rpms here).
This PR implements this new "--root-dir" option.
It also tweaks print_configuration to make it easier to
test. With that we could drop parts of the tests for
PR#1820 from the container.rs and move them in here.
(c.f. osbuild/images#1988)