Skip to content

oci/layout: add GetLocalBlobPath() #2728

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.

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

Merged
merged 2 commits into from
Feb 20, 2025
Merged

Conversation

Luap99
Copy link
Member

@Luap99 Luap99 commented Feb 20, 2025

The podman artifact store needs a method to get the actual local path on disk to the blobs. This is needed so we can then bind mount the files into the container, of course the caller must ensure we treat the files as read only. The digest based nature of the store will break if the files are modified.

@Luap99
Copy link
Member Author

Luap99 commented Feb 20, 2025

@mtrmac PTAL, no idea if this is the right approach.

One thing I noticed the blob files are written with 644 perms, would it make more sense to chmod that to 444 instead? That way we can better avoid someone accidentally writing the file I think.

Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

ACK, this makes sense.

Note the part about non-existent digests.


One thing I noticed the blob files are written with 644 perms, would it make more sense to chmod that to 444 instead? That way we can better avoid someone accidentally writing the file I think.

That’s certainly a good idea for files below imgspecv1.ImageBlobsDir; it wouldn’t work to just replace the mode values, because we tend to os.WriteFile without checking for pre-existing files — that would need to be adjusted.

I’m a bit more worried about the non-digest files like ImageIndexFile, I can imagine (but I have never heard of) users who have scripts that write to oci: and then edit those files directly.

@Luap99
Copy link
Member Author

Luap99 commented Feb 20, 2025

One thing I noticed the blob files are written with 644 perms, would it make more sense to chmod that to 444 instead? That way we can better avoid someone accidentally writing the file I think.

That’s certainly a good idea for files below imgspecv1.ImageBlobsDir; it wouldn’t work to just replace the mode values, because we tend to os.WriteFile without checking for pre-existing files — that would need to be adjusted.

Yeah I don't know how thes eparts here work, mostly wondering if we should protect ourselves so that API is not abused to write directly (and yeah if someone wants they can just chmod it back so it is not like it helps security).
For podman I make sure we do a read only bind mount so the mode itself doesn't matter.

@mtrmac
Copy link
Collaborator

mtrmac commented Feb 20, 2025

Yeah I don't know how thes eparts here work

FWIW, the code has, so far, been the simplest implementation possible, there is no “deep sense” to it. E.g. it doesn’t do any locking because we couldn’t find a reliable cross-platform way to do it, so the transport just punts on that problem and lets callers handle that.

This is not really an internal error, the caller gave us the wrong type
so say that.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The podman artifact store needs a method to get the actual local path on
disk to the blobs. This is needed so we can then bind mount the files
into the container, of course the caller must ensure we treat the files
as read only. The digest based nature of the store will break if the
files are modified.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

Thanks!

@mtrmac mtrmac merged commit 1c9baac into containers:main Feb 20, 2025
10 checks passed
@Luap99 Luap99 deleted the oci-blob-path branch February 20, 2025 18:01
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.

2 participants