Skip to content
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

rawhide: storage-opt is doing more permanent clobbering (uidmap) #15977

Closed
edsantiago opened this issue Sep 28, 2022 · 2 comments
Closed

rawhide: storage-opt is doing more permanent clobbering (uidmap) #15977

edsantiago opened this issue Sep 28, 2022 · 2 comments
Assignees
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@edsantiago
Copy link
Member

edsantiago commented Sep 28, 2022

Followup to #15698.

# podman run --rm --uidmap 0:100:10000 quay.io/libpod/testimage:20220615 date
Wed Sep 28 14:48:41 UTC 2022

# podman --storage-opt=mount_program=/bin/false info &>/dev/null

# podman run --rm --uidmap 0:100:10000 quay.io/libpod/testimage:20220615 date
Error: open /etc in the container: no such file or directory

From this point on, nothing will ever work again with --uidmap, until podman system reset.

podman-4.3.0~rc1-1.fc38.x86_64 , kernel 6.0.0-0.rc7.47.fc38.x86_64 (also 6.0.0-0.rc6.20220922gitdc164f4fb00a.43.fc38.x86_64)

Discovered in rawhide gating tests.

edsantiago added a commit to edsantiago/libpod that referenced this issue Sep 28, 2022
I was testing --log-level by --storage-opt=mount_program=/bin/false

Stop doing that. It's just constantly breaking everything (containers#15698
and containers#15977).

I am violently of the opinion that a command-line option must
not destroy a user's system (except for --set-something, --config,
something that makes it very very clear that it is a lasting
change). I seem to be in the minority on this opinion. So, I
give up.

Signed-off-by: Ed Santiago <[email protected]>
@giuseppe
Copy link
Member

how is it different from #15698?

Setting the mount_program is a destructive operation since it changes the way the files are stored in the local storage. If you are really sure you have not created any image with the mount_program set, you can manually reset the status by deleting the file $GRAPHROOT/overlay/.has-mount-program.

If we want to test --storage-opt=mount_program=/bin/false then we need to make sure we recreate the storage, or use a different storage root for that test.

@edsantiago
Copy link
Member Author

We have fundamentally irreconcilable differences that cannot be resolved, so I yield. #15981 (merged) removes my use of --storage-opt from system tests. May this issue serve as a warning to other curious humans: NEVER EVER PLAY WITH PODMAN OPTIONS. They may destroy your system in unpredictable ways.

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 14, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

No branches or pull requests

2 participants