rootless: don't create a namespace unless for containers-storage

[TristanCacqueray]

This change fixes skopeo usage in restricted environment such as
bubblewrap where it doesn't need extra capabilities or user namespace
to perform its action.

Close #649

Signed-off-by: Tristan Cacqueray tdecacqu@redhat.com

[vrothberg]

This looks like a clever solution to me. @giuseppe PTAL

[giuseppe]

thanks for the patch! Yes, I think it is a good fix, and should also address #652

[TristanCacqueray]

You're welcome, thank you for the prompt review. FWIW I tried using a cleaner method (such as alltransports.ParseImageName) but I couldn't find the right predicate to test for containers-storage type. The proposed solution assumes all the containers-storage image reference start with the containers-storage: prefix.

[giuseppe]

@mtrmac is there any cleaner way to test that? Are you fine with this approach?

[vrothberg]

One way could be to use ref, err := ParseImageName(...) and if err == nil to compare ref.Transport().Name() == storage.Transport.Name().

[TristanCacqueray]

The issue with ParseImageName is that it may fail early with chown /home/fedora/.local/share/containers/storage/vfs: operation not permitted

[vrothberg]

Ouch, sorry for missing that. In this case, we can mimic what ParseImageName(...) effectively does:

parts := strings.SplitN(imgName, ":", 2)
if len(parts) != 2 {
   continue
}
if parts[0] == storage.Transport.Name() { // we have storage reference (but can't validate it yet) }

[TristanCacqueray]

Done, thank you for the suggestion.

[vrothberg]

LGTM, thanks.

@mtrmac @rhatdan PTAL

[vrothberg]

LGTM, thanks.

@mtrmac @rhatdan PTAL

[rhatdan]

LGTM
Although I still want @mtrmac to chime in.

[mtrmac]

The issue with ParseImageName is that it may fail early with chown /home/fedora/.local/share/containers/storage/vfs: operation not permitted

Oh, wow. That’s… a mess.

@nalind AFAICS this is essentially because storageTransport.ParseStoreReference needs a working store so that it can support image ID prefixes:

if img, err := store.Image(possibleID); err == nil && img != nil && len(possibleID) >= minimumTruncatedIDLength && strings.HasPrefix(img.ID, possibleID)

and the like. Is there any chance we could drop that functionality? (I guess not, but it would make dealing with this in callers so much simpler.)

Alternatively, would it be reasonably possible for c/storage.GetStore to return a typed error indicating that “this would work in a user namespace”?

[mtrmac]

(Assuming that we can’t wiggle out of having to do this by changing c/storage or c/image/storage.)

[mtrmac]

(Assuming that we can’t wiggle out of having to do this by changing c/storage or c/image/storage.)

[mtrmac]

This is way too imprecise. Instead:

• In the various commands, drop Before: needsReexec
• In each of the command handlers, run something like maybeReexec(inputParameter) only for the relevant parameters, something like:

      inputImageName := image.args[0]
      if err := maybeReexec(inputImageName); err != nil { 
         return err
      }
      … := parseImageSource(ctx, opts.image, inputImageName) // or parseImage or alltransports.ParseImageName

  possibly rearranging this so that the maybeReexecs happen at the start of the command handlers, before any other real work gets done.

[fungi]

Just for another data point, we're temporarily running with a16489e applied in production and it seems to have solved #649 for us. Thanks @TristanCacqueray!

[TristanCacqueray]

@mtrmac Thank you for the suggestions, I think the last change implements them along with containers/image#631 for the TransportFromImageName procedure. Not sure what is the policy around vendoring thus I inlined the c/image change in that PR.

As @fungi mentioned, the opendev.org infrastructure is using a continuously built version of skopeo which triggered the issue of using reexec in unprivileged environment like bubblewrap.

[mtrmac]

ACK to the overall approach.

Not sure what is the policy around vendoring thus I inlined the c/image change in that PR.

Sure. Ideally, update vendor.conf, run make vendor, and commit that as a separate commit from the other changes, in the same PR.

[mtrmac]

ACK to the overall approach.

Not sure what is the policy around vendoring thus I inlined the c/image change in that PR.

Sure. Ideally, update vendor.conf, run make vendor, and commit that as a separate commit from the other changes, in the same PR.

[mtrmac]

That commit does not actually exist yet, which would make make vendor not reproducible. After containers/image#631 is merged, please update this with the actual merge commit and re-vendor.

[TristanCacqueray]

done

[mtrmac]

LGTM. Thanks!