Skip to content

Conversation

@mtrmac
Copy link
Collaborator

@mtrmac mtrmac commented Nov 14, 2019

When pulling images for consumption by the current runtime, reject images that target a different architecture: https://bugzilla.redhat.com/show_bug.cgi?id=1753019 .

WIP:

  • Absolutely untested, beyond that it compiles.
  • I have no idea how this interacts with manifest lists yet.
  • We might want to look for images that would be broken by this (is it possible to run i386 images on x86_64?)
  • This should ideally be tested directly in CRI-O to ensure it behaves reasonably, and the error is propagated all the way up to the pod status.
  • I’d really love to hear opinions on the semantics change of MustMatchRuntimeOS.

@mtrmac mtrmac force-pushed the enforce-architecture branch from 9cb3112 to 7c319f8 Compare November 14, 2019 20:46
Copy link
Member

@vrothberg vrothberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A somehow related libpod PR: containers/podman#4505

I think it's valid to enforce the OS and arch unless explicitly requested by the user. We could add an option to ignore the checks but I haven't heard any user request until now.

copy/copy.go Outdated
c, err := src.OCIConfig(ctx)
if err != nil {
return errors.Wrapf(err, "Error parsing image configuration")
if (wantedOS == "windows" && c.OS == "linux") || (wantedOS != "windows" && c.OS == "windows") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not if wantedOS != c.OS?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This keeps the previous logic unchanged. I didn’t look into why it is written exactly this way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It dates back to 0c75281 but I can't imagine why it was written that way. According to spec, we should understand all values of GOOS (https://golang.org/doc/install/source#environment) which is currently not the case - at least for this specific check.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is somehow still outstanding. The logic predates this PR but I'm convinced it's wrong. @mtrmac, if you prefer, I can open a PR after and take ownership of the consequences.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*shrug* added a commit to simplify it now:

Looking back at older images, docker://busybox:1.21-ubuntu from 2015 does already have "os" and "architecture" filled in, so this seems safe enough.

I’m not exactly sure how we are going to test that this PR does not break compatibility with obscure images… but if we figure that out, we might just as well test both changes at once.

copy/copy.go Outdated
if err != nil {
return errors.Wrapf(err, "Error parsing image configuration")
if (wantedOS == "windows" && c.OS == "linux") || (wantedOS != "windows" && c.OS == "windows") {
return fmt.Errorf("image operating system %q cannot be used on %q", c.OS, wantedOS)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The error message can be misleading as we could force to exchange the image and host via the SystemContext, such that it claims that the "image operating system "linux" cannot be used on "windows"" (when running a linux host). Maybe we can change the wording to "mismatching image operating system: received %q, expected %q"? Same applies to the architecture.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will fix, though I expect the implementation, and so possibly the reporting, will change drastically after the full scope of #753 .

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improved the texts now.

…ture

This has arguably been implied (OTOH, also arguably, it's a breaking change),
make it explicit.

This does not yet implement the semantics.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to make it easier to add architecture checks.

Should not change behavior.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Now it applies better to OSChoice overrides (it does not claim
that the OSChoice is the current runtime OS).

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
@mtrmac mtrmac force-pushed the enforce-architecture branch from 7c319f8 to d68f82e Compare November 22, 2019 14:59
It's unknown why the previous check was so complex.

Looking back at older images, docker://busybox:1.21-ubuntu from 2015
does already have "os" and "architecture" filled in, so this seems safe
enough.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
(i.e. containers-storage:, ostree:, local docker-daemon: ).

This uses the same logic as manifest list choices, so it should be safe,
but it's not 100% certain (e.g. this will probably prevent pulling 386 containers
on x86_64, which is currently possible for non-multi-arch images, at least).

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
@mtrmac mtrmac force-pushed the enforce-architecture branch from d68f82e to d13dc8a Compare November 22, 2019 15:11
@mtrmac mtrmac changed the title WIP RFC: Enforce runtime architecture Untested: Enforce runtime architecture Nov 22, 2019
Copy link
Member

@vrothberg vrothberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @mtrmac

@rhatdan
Copy link
Member

rhatdan commented Nov 22, 2019

LGTM

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

Successfully merging this pull request may close these issues.

3 participants