Bug 771926 - RFE: cpio should support acls, xattrs and file capabilities
Summary: RFE: cpio should support acls, xattrs and file capabilities
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: cpio
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 771134 1546617
TreeView+ depends on / blocked
 
Reported: 2012-01-05 12:06 UTC by Wolfgang Denk
Modified: 2019-03-14 06:46 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1546617 (view as bug list)
Environment:
Last Closed:


Attachments (Terms of Use)

Description Wolfgang Denk 2012-01-05 12:06:43 UTC
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):

cpio-2.11-4.fc16.x86_64

How reproducible:

100%

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
 /tmp/foo/rcp
 /tmp/foo/rlogin
 /tmp/foo/rsh
 10 blocks

3. Check capabilities on the copies.  In all cases we get:

 # getcap -v /tmp/foo/*
 /tmp/foo/rcp
 /tmp/foo/rlogin
 /tmp/foo/rsh

   I. e., the (needed for correct function) capabilities are lost.


Actual results:

Copies have their capabilities lost.

Expected results:

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

Comment 1 Ondrej Vasik 2012-01-05 12:21:39 UTC
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.

Comment 2 Vivek Goyal 2013-03-21 13:20:38 UTC
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.

Comment 3 Ondrej Vasik 2013-03-21 14:12:31 UTC
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.

Comment 4 Vivek Goyal 2013-03-21 15:12:21 UTC
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.

Comment 5 Ondrej Vasik 2013-03-21 15:15:48 UTC
rpm uses its own implementation of cpio format and I'm quite sure it will not work for them.

Comment 13 Jon Masters 2018-02-19 03:54:57 UTC
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

And is something that we should track in Fedora. It'll be something that the kernel team will be interested in as well.

Comment 15 Pavel Raiskup 2018-02-19 08:25:44 UTC
(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 (bug-cpio@gnu.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.

Comment 17 Taras Kondratiuk 2018-02-19 21:20:06 UTC
(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 (bug-cpio@gnu.org).

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?

Comment 18 Pavel Raiskup 2018-02-20 06:28:55 UTC
(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
an issue?

|- 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
discussion:
http://thread.gmane.org/gmane.comp.gnu.tar.bugs/5443
 
> 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
into account.


Note You need to log in before you can comment on or make changes to this bug.