podman: Fails to set 'security.selinux' extended file attribute when moving file inside container
/kind bug
Description
Fails to set ‘security.selinux’ extended file attribute when moving a file to a mapped volume inside a container.
This causes Python’s shutil.move() to raise an exception and commandline mv to output an error message.
I’m not sure if this is actually a Podman bug but version 1.7.0 exhibits this while 1.6.2 doesn’t.
Steps to reproduce the issue:
- On Fedora 31:
mkdir ~/d
2a. podman run -i -t -w /root -v ~/d:/root:rw,z fedora:31 bash -c 'touch /tmp/f && python3 -c "import shutil;shutil.move(\"/tmp/f\", \"f\")"'
or
2b. podman run -i -t -w /root -v ~/d:/root:rw fedora:31 bash -c 'touch /tmp/f && mv /tmp/f .'
Describe the results you received: In both 2a and 2b the file is actually copied, but:
2a:
Traceback (most recent call last): File “/usr/lib64/python3.7/shutil.py”, line 566, in move os.rename(src, real_dst) OSError: [Errno 18] Invalid cross-device link: ‘/tmp/f’ -> ‘f’
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File “<string>”, line 1, in <module> File “/usr/lib64/python3.7/shutil.py”, line 580, in move copy_function(src, real_dst) File “/usr/lib64/python3.7/shutil.py”, line 267, in copy2 copystat(src, dst, follow_symlinks=follow_symlinks) File “/usr/lib64/python3.7/shutil.py”, line 209, in copystat _copyxattr(src, dst, follow_symlinks=follow) File “/usr/lib64/python3.7/shutil.py”, line 165, in _copyxattr os.setxattr(dst, name, value, follow_symlinks=follow_symlinks) PermissionError: [Errno 13] Permission denied: ‘f’
2b:
mv: setting attribute ‘security.selinux’ for ‘security.selinux’: Permission denied
Describe the results you expected: I expected the file to be moved without any errors.
Additional information:
Moving files from /tmp to /tmp, from /root to /root or from /root to /tmp doesn’t cause any problems.
Output of podman version:
podman version 1.7.0
Output of podman info --debug:
debug:
compiler: gc
git commit: ""
go version: go1.13.5
podman version: 1.7.0
host:
BuildahVersion: 1.12.0
CgroupVersion: v2
Conmon:
package: conmon-2.0.9-2.fc31.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.9, commit: 7d46f3e7711aa3578488284ae2f98b447658f086'
Distribution:
distribution: fedora
version: "31"
IDMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
MemFree: 164462592
MemTotal: 2077921280
OCIRuntime:
name: crun
package: crun-0.10.6-1.fc31.x86_64
path: /usr/bin/crun
version: |-
crun version 0.10.6
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
SwapFree: 2146693120
SwapTotal: 2217734144
arch: amd64
cpus: 2
eventlogger: journald
hostname: fedora31.localdomain
kernel: 5.4.12-200.fc31.x86_64
os: linux
rootless: true
slirp4netns:
Executable: /usr/bin/slirp4netns
Package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
Version: |-
slirp4netns version 0.4.0-beta.3+dev
commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
uptime: 10h 47m 50.76s (Approximately 0.42 days)
registries:
search:
- docker.io
- registry.fedoraproject.org
- registry.access.redhat.com
- registry.centos.org
- quay.io
store:
ConfigFile: /home/vagrant/.config/containers/storage.conf
ContainerStore:
number: 13
GraphDriverName: overlay
GraphOptions:
overlay.mount_program:
Executable: /usr/bin/fuse-overlayfs
Package: fuse-overlayfs-0.7.5-2.fc31.x86_64
Version: |-
fusermount3 version: 3.6.2
fuse-overlayfs: version 0.7.5
FUSE library version 3.6.2
using FUSE kernel interface version 7.29
GraphRoot: /home/vagrant/.local/share/containers/storage
GraphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
ImageStore:
number: 2
RunRoot: /run/user/1000/containers
VolumePath: /home/vagrant/.local/share/containers/storage/volumes
Package info (e.g. output of rpm -q podman or apt list podman):
podman-1.7.0-2.fc31.x86_64
Additional environment details (AWS, VirtualBox, physical, etc.): The above info is from a VirtualBox Fedora 31 VM but it can be reproduced on a physical Fedora 31 machine too. I haven’t tried reproducing it on other platforms.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 1
- Comments: 22 (15 by maintainers)
That’s not just Python related. The same problem occurs while running a Fedora 34 container using Podman on a Fedora 34 system and calling the
mvprogram from coreutils.@rhatdan do you know if a python bug got filed? I’m running into this now and this closed issue is at the top of the search results pile.