Skip to content

Conversation

Johan-Liebert1
Copy link
Collaborator

@Johan-Liebert1 Johan-Liebert1 commented May 7, 2025

Updated to check for root instead of checking if we're inside a podman container

src/oci/mod.rs Outdated
@@ -13,6 +13,7 @@ use oci_spec::image::{Descriptor, ImageConfiguration, ImageManifest, MediaType};
use sha2::{Digest, Sha256};
use tokio::{io::AsyncReadExt, sync::Semaphore};

use crate::util::is_podman_container;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd just inline that. Either as a function in the same file or just directly inline... I'd inline the constant, too :)

src/oci/mod.rs Outdated
@@ -69,7 +70,8 @@ type ContentAndVerity<ObjectID> = (Sha256Digest, ObjectID);
impl<ObjectID: FsVerityHashValue> ImageOp<ObjectID> {
async fn new(repo: &Arc<Repository<ObjectID>>, imgref: &str) -> Result<Self> {
// See https://github.com/containers/skopeo/issues/2563
let skopeo_cmd = if imgref.starts_with("containers-storage:") {
// TODO: Also check here for Docker container...
let skopeo_cmd = if imgref.starts_with("containers-storage:") && !is_podman_container() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think this check is completely correct. It would break my usecase for sure.

Specifically: I'm running in a toolbox, as a non-root user, and when I want to pull skopeo containers-storage: URLs I want to use podman unshare to escape the container. It's a very common practice to have some kind of a flatpak-spawn --host-based script for that in toolbox-type environments...

Checking if we were root would get a bit closer to a solution here, I guess...

What happened to the idea of mounting the container's rootfs inside of itself using --mount= and building the image from that?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Checking if we were root would get a bit closer to a solution here, I guess...

Probably, but I think what we actually need anyways is to override the proxy configuration entirely anyways - ref bootc-dev/bootc#1292 (comment) right?

What happened to the idea of mounting the container's rootfs inside of itself using --mount= and building the image from that?

A bit confused by that; / is already the merged rootfs, why would we mount it again?
But the real problem is that we don't want the merged root, we want the layers so we can store them separately and we want the manifest/config.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Interesting. I didn't think about the config, but I guess that has some useful stuff in it.

Why do we want to store the layers separately?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Why do we want to store the layers separately?

I think it's a fundamental advantage of OCI that it has the concept of layers, and we don't want to re-fetch layers that didn't change across updates. Using intelligently split layers is a huge network optimization.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sure, but by the time we go to install the image, we've already downloaded the entire thing, no?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yep absolutely, but we want to retain distinct knowledge of the layers so that the next bootc upgrade doesn't re-fetch all of the content again (xref bootc-dev/bootc#1197 ) and we only have a hope of doing that if we retain knowledge of the layer structure.

Copy link
Collaborator

Choose a reason for hiding this comment

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

True.

Calling `podman unshare` from inside a rootful container fails,
which breaks image pulls in said case. We have sufficient privileges
to pull from containers storage if we are in a rootful container thus
don't need unshare

Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>
@Johan-Liebert1 Johan-Liebert1 changed the title Only use podman unshare outside of a container Only use podman unshare if not root Jun 18, 2025
Copy link
Collaborator

@allisonkarlitskaya allisonkarlitskaya left a comment

Choose a reason for hiding this comment

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

Thanks!

@allisonkarlitskaya allisonkarlitskaya merged commit 9b6b2a0 into containers:main Jun 18, 2025
12 checks passed
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