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

podman tries to make user-executable directory world-executable (rootless) #23028

Closed
myllynen opened this issue Jun 18, 2024 · 3 comments · Fixed by #23032
Closed

podman tries to make user-executable directory world-executable (rootless) #23028

myllynen opened this issue Jun 18, 2024 · 3 comments · Fixed by #23032
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@myllynen
Copy link

Issue Description

When a directory in the path configured in containers.conf is not world-executable podman fails to run containers:

admin@bastion:~> cat ~/.config/containers/storage.conf                                                                                                
[storage]
driver = "overlay"
runroot = "/app/admin/ee/runroot"
graphroot = "/app/admin/ee/graphroot"
rootless_storage_path = "/app/admin/ee/storage"
[storage.options]
pull_options = {enable_partial_images = "false", use_hard_links = "false", ostree_repos=""}
[storage.options.overlay]
mountopt = "nodev,metacopy=on"
admin@bastion:~> id
uid=4444(admin) gid=4444(admin) groups=4444(admin),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
admin@bastion:~> ls -alZ /app
total 0
drwxr-x---.  3 root  admin unconfined_u:object_r:default_t:s0            19 2024-06-07 12:53 .
dr-xr-xr-x. 19 root  root  system_u:object_r:root_t:s0                  246 2024-06-06 12:46 ..
drwxr-x--x.  3 admin admin unconfined_u:object_r:container_var_lib_t:s0  16 2024-06-07 13:28 admin
admin@bastion:~> strace -ff podman run -ti test-container uname 2>&1 | grep chmod | grep -i perm
[pid  3400] fchmodat(AT_FDCWD, "/app", 0751) = -1 EPERM (Operation not permitted)
[pid  3400] rt_sigreturn({mask=[]}Error: chmod /app: operation not permitted
admin@bastion:~> podman version
Client:       Podman Engine
Version:      4.9.4-rhel
API Version:  4.9.4-rhel
Go Version:   go1.21.7 (Red Hat 1.21.7-2.module+el8.10.0+21638+b01be198)
Built:        Mon Jun 10 14:56:14 2024
OS/Arch:      linux/amd64
admin@bastion:~> 

The top-level directory is already user-readable/executable but podman still tries to make it world-executable.

If doing "chmod o+x /app" as root then the test would work as expected.

If this is indeed required then at least the error message should be clearer.

Steps to reproduce the issue

See above - any directory in the path, even if user-readable/executable, not world-executable will cause podman to fail.

Describe the results you received

Directories must be world-executable or podman fails.

Describe the results you expected

It is enough for directories to be owned and accessible by the user.

podman info output

If you are unable to run podman info for any reason, please provide the podman version, operating system and its version and the architecture you are running.

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

No

Additional environment details

Additional environment details

Additional information

Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting

@myllynen myllynen added the kind/bug Categorizes issue or PR as related to a bug. label Jun 18, 2024
@giuseppe
Copy link
Member

The top-level directory is already user-readable/executable but podman still tries to make it world-executable.

If doing "chmod o+x /app" as root then the test would work as expected.

that won't be enough when you run inside a user namespace (for rootless a nested namespace), since your UID:GID could not be mapped in the inner namespace.

@giuseppe
Copy link
Member

and we probably don't need this code anymore, the OCI runtime takes advantage of the new Linux mount API to achieve it without requiring the chmod hack we needed before

@giuseppe
Copy link
Member

opened a PR, let's see how far it goes in the CI: #23032

giuseppe added a commit to giuseppe/libpod that referenced this issue Jun 21, 2024
if the current user is not mapped into the new user namespace, use an
intermediate mount to allow the mount point to be accessible instead
of opening up all the parent directories for the mountpoint.

Closes: containers#23028

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
@stale-locking-app stale-locking-app 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 21, 2024
@stale-locking-app stale-locking-app bot locked as resolved and limited conversation to collaborators Sep 21, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants