-
Notifications
You must be signed in to change notification settings - Fork 785
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
Run stat command directly for volume ownership test #2236
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,10 @@ | ||
FROM alpine | ||
ADD test-ownership /usr/bin/ | ||
RUN adduser -D -H testuser && addgroup testgroup | ||
RUN mkdir -p /vol/subvol | ||
RUN chown testuser:testgroup /vol/subvol | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Out of curiosity, what is the purpose of the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually it is necessary. The original bug only showed up when the volume cache was in play. And that only happens if there are additional I chose that particular command because it obviously shouldn't have changed the permissions of the volume ... but it did. I can add a commit with a comment in the Dockerfile to try to summarize the reasoning if you think it would be helpful. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Given what you just said, I think a comment is not only helpful but critical: a future maintainer might have no idea of this context, and could easily refactor/optimize away the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added a comment. Not sure what your feelings are about github links in source, but the comment above the |
||
VOLUME /vol/subvol | ||
|
||
# Run some command after VOLUME to ensure that the volume cache behavior is invoked | ||
# See https://github.com/containers/buildah/blob/843d15de3e797bd912607d27324d13a9d5c27dfb/imagebuildah/stage_executor.go#L61-L72 and | ||
# for more details | ||
RUN touch /test |
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, I'm a complete ignoramus about the VOLUME directive, and I could test this (and will, when I get some time this morning), but: how would this behave differently if the Containerfile did not specify
VOLUME
? Is there any way to check that/vol/subvol
is actually being treated as a volume, and not just a regular subdirectory in the image?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tldr; I wasn't able to find a good way.
Volumes are mount points in containers so I figured I could use
mountpoint
to test the directory, but ...😟
I can't seem to get consistent results from
stat -c "%i
orstat -f
inside the container either. We could parsemount
ordf
, but ... gross.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. Thanks for having looked into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@edsantiago The VOLUME directive tells the container engines to allocate a UNNAMED volume on disk and mount it at the /vol/submount directory.
The problem was podman was creating the new volume with the wrong owner/permissions and then mounting over the /vol/submount. The directory went from ownership testuser testgroup to root root.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@carbonin, I can confirm:
mountpoint -n
,-d
,blkid
,stat -c %i
, none of those (or others I've forgotten) produce any useful distinction.