Description of problem:
Copying files using "cpio" drops file capabilities. It appears this
tool does not even provide any options to deal with such attributes
or ACLs or ...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Select some files that have capabilities set:
# cd /usr/bin
# getcap -v rcp rlogin rsh
rcp = cap_net_bind_service+ep
rlogin = cap_net_bind_service+ep
rsh = cap_net_bind_service+ep
2. Copy files to some other place:
# rm -fr /tmp/foo
# mkdir /tmp/foo
# ls rcp rlogin rsh | cpio -vBpdum /tmp/foo
3. Check capabilities on the copies. In all cases we get:
# getcap -v /tmp/foo/*
I. e., the (needed for correct function) capabilities are lost.
Copies have their capabilities lost.
There should be a way that all tools that deal with archiving,
restoring and copying of files not only include the easily visible
ownership and file permission information, but also the more delicate
and less visible features like capabilities.
See bugs # 771134 and 693731
It would definitely need new format - as in current cpio format headers there is definitely no room for storing such things. It is nice to have RFE... marking it RFE.
Is there any update on this issue? We will need xattr support in cpio. Given the secureboot features now, for kexec/kdump we might sign /sbin/kexec binary. Signing will happen using IMA and that stores signatures in xattr. That means cpio needs to support atleast xattr so that signatures can be transferred to target system.
No progress - and to be honest, I don't think this is good idea. Upstream of cpio is mostly in maintainance mode - this would mean support for pax format (POSIX 2001). At the moment, cpio supports only ustar (POSIX-1998) format. Given the fact that even in tar, which is much more active, it took 6 years, to get the extended attributes support upstream, it is probably unrealistic. Btw. bsdcpio already has support for pax format.
so should we ship and use bsdcpio instead? BTW, what does rpm use. Because ultimately I want to make sure that files contained in rpms built at build
services have signatures and these signatures are transferred to target when rpm is installed.
rpm uses its own implementation of cpio format and I'm quite sure it will not work for them.
This has now been proposed upstream:
[PATCH v2 00/15] extend initramfs archive format to support xattrs
And is something that we should track in Fedora. It'll be something that the kernel team will be interested in as well.
(In reply to Jon Masters from comment #13)
> This has now been proposed upstream:
> [PATCH v2 00/15] extend initramfs archive format to support xattrs
It is not yet proposed upstream yet (firstname.lastname@example.org).
Btw. can we elaborate on this point?
| - Add TAR support. Complicated format and big headers looks like too
| much overhead.
> And is something that we should track in Fedora. It'll be something that the
> kernel team will be interested in as well.
Trying to invent xattrs into cpio format doesn't sound wise to me; xattrs
support is not yet standardized for pax format and it is impossible to
implement it within ustar format. xattrs are "obsoleted" by the world
except for linux (by NFSv4 ACLs), POSIX.1e dropped.
By the RFE here in bugzilla I rather thought that 'cpio' utility could
support xattrs through 'pax' format one day.
(In reply to Pavel Raiskup from comment #15)
> (In reply to Jon Masters from comment #13)
> > This has now been proposed upstream:
> > [PATCH v2 00/15] extend initramfs archive format to support xattrs
> > https://lkml.org/lkml/2018/1/24/857
> It is not yet proposed upstream yet (email@example.com).
I'd like to get feedback from kernel first.
> Btw. can we elaborate on this point?
> | - Add TAR support. Complicated format and big headers looks like too
> | much overhead.
See here: https://lkml.org/lkml/2018/2/17/50
> > And is something that we should track in Fedora. It'll be something that the
> > kernel team will be interested in as well.
> Trying to invent xattrs into cpio format doesn't sound wise to me; xattrs
> support is not yet standardized for pax format and it is impossible to
> implement it within ustar format. xattrs are "obsoleted" by the world
> except for linux (by NFSv4 ACLs), POSIX.1e dropped.
What is the proposed replacement for xattrs?
(In reply to Taras Kondratiuk from comment #17)
> I'd like to get feedback from kernel first.
I personally would go with GNU cpio/libarchive first, though. At least
to get an idea how realistic is to enhance obsoleted cpio formats.
> > Btw. can we elaborate on this point?
> > | - Add TAR support. Complicated format and big headers looks like too
> > | much overhead.
> See here: https://lkml.org/lkml/2018/2/17/50
| - ustar+pax header is *huge*. E.g. directory entry in archive: pax 1536
| bytes vs cpio <200 bytes. Overall compressed initramfs size increase
| is not significant though.
The extended header block is optional, but likely when storing xattrs
you'll likely waste the space for good. I think that the standard
could be optimized (in theory) by some kind of in-lining, but only the
portability matters here rather then size of _uncompressed_ format.
How big is the directories vs. files ratio to consider this to be
|- pax is not a strict format. E.g. xattrs may be stored under different
| names: SHCILY.xattr (GNU tar, star) vs LIBARCHIVE.xattr (libarchive).
Pax is strict format. The capital-keywords have user-defined semantics,
but still need to follow the syntax to make it a valid archive.
The problem here is that nobody went that far to properly standardize
xattr=* namespace (lower-case keyword, see pax format), see upstream
> What is the proposed replacement for xattrs?
Sorry, when I see xattrs+tar, I mistakenly replace that with ACLs
and capabilities. Yes, xattrs are probably fine though Solaris seems
to have some next generation extended attributes - and if one was
about to standardize xattrs in pax format - those should be too taken