Description of problem: currently tmpfs does not seem to support file capabilities and rpm is blowing up when installing in a mock environment on a tmpfs file system.
When files are marked to have file system based capabilities, that is basically a request for setuid on older kernels or if someone has compiled their kernel without file system based capabilities turned on.
Currently rpm makes no attempt to work around missing capability support. The idea of automatically falling back to SUID when capability support is missing, while kinda obvious, makes me feel more than a little bit uneasy: we'd then have the same packages with different privileges given based on arbitrary local filesystem setup. Who's going to track all the possible variants in case of vulnerabilities or other possible breakage due to capability / SUID differences? For purposes of building in mock, it'd probably be sufficient to be able to tell rpm to just completely skip the capabilities (no such flag exists currently but can be added). Its the "real world" use with old (think NFS) and/or exotic filesystems that IIRC stopped the previous round of attempting getting capabilities into use within Fedora.
I would think it would be safer and better to install no capabilities with a complaint. But not a failure. I think mock builds would work then.
I'm not entirely sure mock will work with no capabilities... but it's possible. Can someone attach a tmpfs failing mock root.log?
Not much to see, really; it comes down to this: Transaction Summary ================================================================================ Install 86 Package(s) Total size: 45 M Installed size: 190 M Error unpacking rpm package iputils-20101006-3.fc15.x86_64 error: unpacking of archive failed on file /bin/ping: cpio: cap_set_file failed - Operation not supported Error unpacking rpm package policycoreutils-2.0.84-3.fc15.x86_64 error: unpacking of archive failed on file /usr/sbin/seunshare: cpio: cap_set_file failed - Operation not supported 1124 blocks I'll attach a full log.
Created attachment 468940 [details] root.log from failing mock build
I have moved seunshare out of the policycoreutils package into the policycoreutils-sandbox package, which will allow policycoreutils to install and should allow fix some of the problem. I believe seunshare should be in that directory.
Panu what are your current thoughts on this?
*** Bug 699898 has been marked as a duplicate of this bug. ***
*** Bug 699895 has been marked as a duplicate of this bug. ***
As can be seen from the duplicates this is also an issue for hosts with NFS root. For such hosts it is impossible to upgrade glibc-common. In these cases most binaries fail to execute and the system is essentially unusable. After upgrading to FC15 I now have such a host in this state and would class this bug as urgent in priority. I'm sure everyone else with NFS root machines would too :(
Given that this blocks updates on diskless NFS-root machines, I think the severity/priority ought to be significantly higher than low/medium.
I guess we should also question why NFS does not support file capabilities?
I can confirm this problem with latest mock on RHEL6, trying to set up a tmpfs-based chroot for Fedora 15 target: error: unpacking of archive failed on file /usr/libexec/pt_chown: cpio: cap_set_file failed - Operation not supported HTH.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Still valid on Fedora 17. Are there any plans to get this one fixed?
In addition to glibc-common not updating, I saw that httpd doesn't install on an NFS-root machine. It fails when unpacking /usr/sbin/suexec. Is there even a workaround for these cases?
> Is there even a workaround for these cases? In those cases where the NFS server is "compatible enough", one can do a chroot to the exported root, and upgrade those packages on the server. Then do "chmod u+s" on the problematic files, so they will work on the client. If the server is too different from the client, this won't work, but it is a workaround for some cases.
The problem is, that rpm installation itself will fail, when caps cannot be set.
If that was a comment to my comment 19: on the NFS server, the capabilities CAN be set. There, the file system is local. The capabilities will have no effect, since they won't be seen by the client. That is why one has to do the chmod afterwards.
Ah, now I got what you mean. Not a real option here.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
I can confirm something very similar to this on an ARM system without NFS, see my bug 1007064.
I can confirm that this is a problem with the mock root on glusterfs using glusters inbuilt NFS access for diskless-nfs machines error: unpacking of archive failed on file /usr/bin/systemd-detect-virt: cpio: cap_set_file failed - Operation not supported error: systemd-208-14.fc20.i686: install failed No easy work around as the there is no access to the filesystem that has capabilities.
and the same problem occur when thry to build rhel7 packages on rhel6 host in mock.
and the same problem occurs when trying to build f20 packages on a RHEL 6 OBS build system in tmpfs.
Still a problem on Rawhide, building in a chroot.
*** Bug 1007064 has been marked as a duplicate of this bug. ***
Also seeing this building any package for EPEL7 using mock, on a CentOS 6.5 box.
I've figured out what was causing this issue, at least for me. I was building using an LXC container which was dropping setfcap, so all I had to do was remove the line dropping it from my LXC container. Just thought I'd leave this comment here for anyone else whose web searches lead them to this bug report. My apologies for adding additional noise to this issue.
I just ran into this issue while evaluating RHEL7 / CentOS 7 as an option in a NFS root + NetApp environment. Is there any chance that this will be fixed or is it even possible? Otherwise RHEL 7 is not a suitable solution for some enterprise use cases. Essentially RedHat Enterprise Linux is unusable as NFS root client. Error unpacking rpm package httpd-2.4.6-19.el7.centos.x86_64 error: unpacking of archive failed on file /usr/sbin/suexec: cpio: cap_set_file
Another data point (and possible workaround). I had a similar mock chroot build that failed. Chroot is centos 7 (and failed package was systemd). Host Debian 8 (Jessie). The thing is that the host is running in a schroot chroot using aufs. Removing the copy-on-write functionality (yes, I know what mock does. There are still reasons for running it in a COW schroot. Never mind that) avoided the problem.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
If it's not practical for rpm installation to fall back on suid somehow, then I guess NFS needs support, which means writing a protocol draft, getting it reviewed by the ietf working group, and then upgrading both client and server. On the other hand, I think that all may be required is a single new "capability" attribute for NFSv4.2, which shouldn't be hard, and the ietf process shouldn't be a big deal if we have a good explanation of the use case here.
That said.... (In reply to Panu Matilainen from comment #2) > The idea of automatically falling back to SUID when capability support is > missing, while kinda obvious, makes me feel more than a little bit uneasy: I think we need to look very hard at the possibility of falling back on SUID, if only to ensure we have an ironclad argument for new protocol support. Without the fallback we're telling people "sorry we're no longer supporting root on NFS until you upgrade your server to something that doesn't exist yet." > we'd then have the same packages with different privileges given based on > arbitrary local filesystem setup. Who's going to track all the possible > variants in case of vulnerabilities I guess this would mean we'd need to continue treating a bug as a vulnerability if it would be one in the SUID case--is that so hard? > or other possible breakage due to capability / SUID differences? Do you have any examples in mind?
I just encountered this problem with a chroot build environment on an NFS server in this dependency chain: shell script uses "usleep" -> requires initscripts -> requires iputils -> includes "ping" => build fails because capabilities on the "ping" executable can't be set Doesn't look this kind of ridiculous? In my specific case I can fall back to "sleep" (and I will), but it's a sad fact that many packages (any package requiring "systemd", for example) can't be built on an NFS chroot, and that his situation has been unchanged over 5 years.
Just in case someone else gets confused like myself - "Recent" Linux distributions support "security.selinux" xattrs (aka SELinux labels) with NFS v4.2, but "security.capability" still seems to be unsupported. The following test was made on F21. # grep /mnt/nfs /proc/self/mounts localhost:/ /mnt/nfs nfs4 rw,seclabel,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1 0 0 # getfattr -n security.selinux /mnt/nfs/ping # file: mnt/nfs/ping security.selinux="unconfined_u:object_r:usr_t:s0" # getfattr -n security.capability /mnt/nfs/ping /mnt/nfs/ping: security.capability: Operation not supported
Fedora 24, ARM 32 bit problem as well : # dnf update iputils Last metadata expiration check: 2:15:30 ago on Tue Oct 4 18:11:45 2016. Dependencies resolved. ======================================================================================= Package Arch Version Repository Size ======================================================================================= Upgrading: iputils armv7hl 20160308-3.fc24 updates 160 k Transaction Summary ======================================================================================= Upgrade 1 Package Total download size: 160 k Is this ok [y/N]: y Downloading Packages: iputils-20160308-3.fc24.armv7hl.rpm 858 kB/s | 160 kB 00:00 --------------------------------------------------------------------------------------- Total 42 kB/s | 160 kB 00:03 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Upgrading : iputils-20160308-3.fc24.armv7hl 1/2 Error unpacking rpm package iputils-20160308-3.fc24.armv7hl Error unpacking rpm package iputils-20160308-3.fc24.armv7hl error: unpacking of archive failed on file /usr/bin/ping;57f3f48d: cpio: cap_set_file iputils-20160308-3.fc24.armv7hl was supposed to be installed but is not! Verifying : iputils-20160308-3.fc24.armv7hl 1/2 iputils-20121221-4.fc20.armv7hl was supposed to be removed but is not! Verifying : iputils-20121221-4.fc20.armv7hl 2/2 Failed: iputils.armv7hl 20160308-3.fc24 Complete! # getfattr -n security.selinux /usr/bin/ping /usr/bin/ping: security.selinux: Operation not supported # getfattr -n security.capability /usr/bin/ping /usr/bin/ping: security.capability: Operation not supported # grep ' / ' /proc/self/mounts rootfs / rootfs rw 0 0 /dev/mmcblk0p1 / ext4 rw,noatime,barrier=1,data=ordered 0 0
Happened for me when building a F25 chroot using dnf --root: Installing : iputils-20160308-3.fc25.0.riscv64.riscv64 158/170 Error unpacking rpm package iputils-20160308-3.fc25.0.riscv64.riscv64 Error unpacking rpm package iputils-20160308-3.fc25.0.riscv64.riscv64 error: unpacking of archive failed on file /usr/bin/ping;57f66987: cpio: cap_set_file error: iputils-20160308-3.fc25.0.riscv64.riscv64: install failed
While this doesn't solve the issue of NFS not having support for capabilities, I'd like to note that I've had success using a filesystem that does on an iSCSI target and using netroot= and root= on the kernel command line (iSCSI initiation is done by a dracut module). When combining Debian's overlay-root dracut module with a squashfs iSCSI target, PXE-bootable Fedora live systems become a little more interesting: https://anonscm.debian.org/git/collab-maint/dracut.git/tree/debian/90overlay-root Also see: http://lass.cs.umass.edu/papers/pdf/FAST04.pdf
*** Bug 1350476 has been marked as a duplicate of this bug. ***
I have managed to find a workaround for this issue, which at least allows me to upgrade packages: the capabilities will not get set, so "ping" won't work, but I can fix that in other ways (eg setuid) if needed. Create cap_set_file.c: >>> #include <sys/capability.h> int cap_set_file(const char *path_p, cap_t cap_p) { return 0; } <<< Then: yum install gcc libcap-devel gcc -Wall -shared -ocap_set_file.so cap_set_file.c env LD_PRELOAD=`pwd`/cap_set_file.so yum update
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Applies to Fedora 27. Please update Version to reflect.
FWIW (very little, very late I'm afraid), rpm >= 4.14.0 has --nocaps option you can use to work around filesystems that don't support capabilities. Not saying the case is fixed, but at least it makes installations possible: https://github.com/rpm-software-management/rpm/commit/0216aaec69feb0bb619dbc59ed77db6de3902b0c
(In reply to Panu Matilainen from comment #47) > FWIW (very little, very late I'm afraid), rpm >= 4.14.0 has --nocaps option > you can use to work around filesystems that don't support capabilities. Not > saying the case is fixed, but at least it makes installations possible: > https://github.com/rpm-software-management/rpm/commit/ > 0216aaec69feb0bb619dbc59ed77db6de3902b0c Useful to know, thanks! I'm happy to help with NFS protocol extensions to support file capabilities, by the way, but would like to collaborate with someone who's more of an expert on them.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
me too. We use NFS-root booting for embedded-type machines (vme processors, raspberry pi, etc) where we do not want the root filesystem to be on local flash (hard to maintain machines in remote physical locations). For now we use "yum versionlock" the offending packages as a workaround. But I find it not amusing at all that NFS-Root, a feature of UNIX and Linux for 100 years, has been broken for no good reason (add "--nocaps" or a true "--force" to yum/rpm already!). K.O.
For what it's worth, note that Chuck Lever has done a little work on an NFS protocol extension to support capabilities; latest I've seen from him on that subject: https://www.ietf.org/mail-archive/web/nfsv4/current/msg16220.html Of course even with that done it will only help once both client and server support it, so if there were a workaround in the absence of this support that would still be useful for someone who's stuck with an NFS server that doesn't have the right support.
My reading of the proposed NFSv4 extension document is that it adds a bunch of stuff, but not for security.capabilities, so no help here. https://datatracker.ietf.org/doc/draft-ietf-nfsv4-integrity-measurement/?include_text=1 K.O.
(In reply to Konstantin Olchanski from comment #52) > My reading of the proposed NFSv4 extension document is that it adds a bunch > of stuff, > but not for security.capabilities, so no help here. Right, that's why I linked to the email, not the draft; in his email there's brief discussion of his plans for capabilities. Sorry for the confusion. (You can also look up his earlier draft which included a proposal for capabilities, but it's not how we'll end up doing it.)
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Still applies in F30.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Please reopen against F30.
(In reply to Patrick Smears from comment #43) > I have managed to find a workaround for this issue, which at least allows me > to upgrade packages: the capabilities will not get set, so "ping" won't > work, but > I can fix that in other ways (eg setuid) if needed. Note that with newer versions of RPM, the contents of cap_set_file.c need to be slightly longer: >>> #include <sys/capability.h> int cap_set_file(const char *path_p, cap_t cap_p) { return 0; } int cap_set_fd(int fd, cap_t caps) { return 0; } <<< The commands remain: > yum install gcc libcap-devel > gcc -Wall -shared -ocap_set_file.so cap_set_file.c > env LD_PRELOAD=`pwd`/cap_set_file.so yum update