buildah: Security xattrs cause copy failures in builds
Description
When trying to ADD a tarball which contains security.capability attributes on files (in my case: /usr/bin/newgidmap from a system image), the ADD operation will fail with an operation not supported error.
There are a few closed issues about this, so, I decided to open a new one: #2127 #2168 #3294
Steps to reproduce the issue:
For this Containerfile, run podman build:
FROM scratch
WORKDIR /
ADD test.tar /
With this for test.tar:
test.tar.zip (because GitHub is obnoxious, I had to put the tarball into a ZIP archive to upload it)
Describe the results you received:
error setting extended attributes on "/usr/bin/newgidmap": setting value of extended attribute "security.capability" on "/usr/bin/newgidmap": operation not supported
Describe the results you expected: Copy should succeed, or the error should be changed to indicate that this is not possible under rootless podman (I don’t believe it is; this may be a bug).
Output of rpm -q buildah or apt list buildah:
$ pacman -Qi buildah | rg Version
Version : 1.29.1-1
Output of buildah version:
Version: 1.29.1
Go Version: go1.20.1
Image Spec: 1.0.2-dev
Runtime Spec: 1.0.2-dev
CNI Spec: 1.0.0
libcni Version: v1.1.2
image Version: 5.24.1
Git Commit: faf0d4fcbaede00f4e615dc5cc2ccc816f240cfe
Built: Mon Feb 20 02:47:12 2023
OS/Arch: linux/amd64
BuildPlatform: linux/amd64
Output of podman version if reporting a podman build issue:
Client: Podman Engine
Version: 4.4.1
API Version: 4.4.1
Go Version: go1.20
Git Commit: 34e8f3933242f2e566bbbbf343cf69b7d506c1cf-dirty
Built: Sat Feb 11 07:18:26 2023
OS/Arch: linux/amd64
Output of cat /etc/*release:
DISTRIB_ID="Arch"
DISTRIB_RELEASE="rolling"
DISTRIB_DESCRIPTION="Arch Linux"
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo
Output of uname -a:
Linux waverider 6.1.12-hardened1-1-hardened #1 SMP PREEMPT_DYNAMIC Thu, 16 Feb 2023 23:55:43 +0000 x86_64 GNU/Linux
Output of cat /etc/containers/storage.conf:
[storage]
driver = "overlay"
runroot = "/run/containers/storage"
graphroot = "/var/lib/containers/storage"
[storage.options]
additionalimagestores = []
pull_options = {enable_partial_images = "false", use_hard_links = "false", ostree_repos=""}
[storage.options.overlay]
mountopt = "nodev"
[storage.options.thinpool]
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 24 (12 by maintainers)
I still don’t get how the command
$ cd /var/lib/containers/ltdk/storage && touch foo && podman unshare attr -s security.capability -V "\1\0\0\2@\0\0\0\0\0\0\0\0\0\0\0\0\0\0" fooworked well for you as rootless, but when Podman does the same thing then it fails.Could you run
attrunder strace so we can check if anything is done differently?$ cd /var/lib/containers/ltdk/storage && touch foo && podman unshare strace -f -s 1000 attr -s security.capability -V "\1\0\0\2@\0\0\0\0\0\0\0\0\0\0\0\0\0\0" foothanks for providing the tarball. I am also unable to reproduce the problem (tried both with and without fuse-overlayfs).
Do you see any difference if you run
podman system reset -ffirst (this is going to destroy all your containers/images!)?I guess you are running on a new enough kernel that you can use native overlay instead of fuse-overlayfs.
No issue on XFS.