|Summary:||The tar-in command does not allow restoring file capabilities|
|Product:||Red Hat Enterprise Linux 8||Reporter:||Pierre Neyron <pierre.neyron>|
|Component:||libguestfs||Assignee:||Richard W.M. Jones <rjones>|
|Status:||CLOSED ERRATA||QA Contact:||YongkuiGuo <yoguo>|
|Version:||8.2||CC:||gveitmic, mickours, praiskup, ptoscano, rjones, swachira, vdanjean.ml, virt-maint, yoguo|
|Fixed In Version:||libguestfs-1.40.2-27.el8||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2021-05-18 15:21:14 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||771927|
Description Pierre Neyron 2016-10-12 22:32:37 UTC
Comment 1 Pierre Neyron 2016-10-12 22:34:58 UTC
sorry for the typo ;-) 3. test the capability with guestfish cap-get-file command: $ guestfish -i -a OS.qcow2 <<EOF cap-get-file /bin/ping EOF
Comment 2 Richard W.M. Jones 2016-10-13 11:49:02 UTC
I think this is really a bug in GNU tar. However I have proposed a patch upstream: https://www.redhat.com/archives/libguestfs/2016-October/msg00089.html
Comment 3 Pavel Raiskup 2016-10-13 12:31:03 UTC
Thanks for the patch. You shouldn't need --xattrs once you use --xatrrs-include (though this implication came about year later after --xattrs-include was added). I have just a warning for you: In case you use --xattrs-include='*', you should really know what are the implications -- kernel might refuse direct writes to some security attributes, or some binary representation of security attributes might change, and if you restore binary capabilities you might easily restore some garbage from the kernel point of view. AFAIK, this has not happened yet, but you should take this into account.
Comment 4 Pierre Neyron 2016-10-14 16:22:31 UTC
What about adding a new option to the guestfish tar-in command to expose the --xattrs-include=XXX option ? -> xattrs-include:XXX That way, it is up to the user to decide if he want to take the risk...
Comment 5 Richard W.M. Jones 2016-10-14 17:01:26 UTC
Yes this is possible, but we'd have to support it in (our) API forever. We'll see if someone reviews the patch on the mailing list.
Comment 6 Richard W.M. Jones 2020-12-11 10:25:40 UTC
I have pushed the patch upstream: https://github.com/libguestfs/libguestfs/commit/6d0ab14b56743679638ead0829ff3131749ac59b
Comment 9 Richard W.M. Jones 2021-01-05 09:09:46 UTC
Upstream commit 6d0ab14b56743679638ead0829ff3131749ac59b.
Comment 13 John Ferlan 2021-01-05 13:53:49 UTC
Altering the assignee to Rich rather than virt-maint since he fixed the issue.
Comment 14 YongkuiGuo 2021-01-06 11:32:05 UTC
Verified with package: libguestfs-1.40.2-27.module+el8.4.0+9282+0bdec052.x86_64 Steps: 1. On rhel8.4 host $ getcap /bin/ping /bin/ping = cap_net_admin,cap_net_raw+p 2. $ tar cf /tmp/ping.tar --xattrs /bin/ping 3. tar-in the archive with the xattr:true option: $ guestfish -i -a rhel8.3.raw tar-in /tmp/ping.tar / selinux:true acls:true xattrs:true 4. $ guestfish -i -a rhel8.3.raw ... Operating system: Red Hat Enterprise Linux 8.3 (Ootpa) /dev/rhel/root mounted on / /dev/sda1 mounted on /boot ><fs> cap-get-file /bin/ping = cap_net_admin,cap_net_raw+p The tar-in command can restore file capabilities correctly. So verified this bug.
Comment 16 errata-xmlrpc 2021-05-18 15:21:14 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:1762