Re: [PATCH v2] Support for PAX extended header and Linux extended attributes

[Guillem Jover <guillem@debian.org>]

Hi!

On Thu, 2016-05-19 at 11:33:27 -0400, Stefan Berger wrote:
> The following patch adds support for the tar pax extended header to the tar
> parser so that tar files with pax extended headers containing Linux extended
> attributes can be processed by dpkg. Essentially the pax extended header
> contains key value pairs that describe file attributes. More information
> about the format can be found here:
> 
> http://pubs.opengroup.org/onlinepubs/009695299/utilities/pax.html#tag_04_100_13_03
> 
> We are particularly interested in the security.ima extended attribute,
> which, if available, contains a signature for the following file in the tar
> and which we then write as a Linux extended attribute into the filesystem.

First of all, thanks for the patch! I've been looking into this the
past several days, and unfortunately I see some problems with the
proposed implementation and probably with this approach in general.

Adding PAX support in itself seems very worthwile to me as that would
fix several limitations in the ustar format we support currently (true
LFS), and would make it more portable (no need to use GNU extensions
to support long names).

The PAX support is not complete though, it's missing global header
support, removal of variables, and overridding of the ustar fields,
and it should probably validate the input and disallow some stuff,
like entries encoded in anything not UTF-8.

But what we'd gain in portability by using the specified parts of PAX
we'd lose by using the vendor specific xattr support, which is not
supported everywhere:

  <https://github.com/libarchive/libarchive/wiki/TarExtendedAttributes>

And if we are not going to be portable anyway (dpkg is being used in
many non-Debian derived, nor Linux-based systems), we might as well
use a Debian or dpkg specific vendor namespace. (TBH I'm also slightly
uncomfortable with using the proposed xattr namespace given the history
with its author, but this is certainly not a showstopper.)

I'm assuming this is primarily (if not exclusively) Linux-specific? Or
are there plans to port it to other kernels?


Then there's the underlaying assumption that xattrs are going to be
supported and enabled by the build-time and install-time systems. Some
time ago when I checked, xattrs were not universally supported by all
filesystems, and were not even enabled by default, has this changed
significantly? I see that Linux supports xattrs for most major ones,
though. I've not checked the status on other Unices yet.

Also to be able to store xattrs under the security namespace requires
privs, which most build daemons and build systems do not have. OTOH
fakeroot does have xattr support, so that would cover that. I'm not
sure if other non-root methods support those too.

There's also the possible problem with reproducibility and who is
supposed to sign those files, the builder, some other intermediate
party who has the distribution private keys, etc. If they need to be
injected, it might be better to store them in an additional .deb
member, in a similar way as the proposed .deb container signatures
in something like the sigs.tar.xz ar member.


In the end it might perhaps make more sense to use some other kind of
manifest file to transport additional file attributes, although using
PAX file keywords seems very appealing indeed. I'm working on adding
mtree(5) support, which I hope to get ready soon, but I'm still uncertain
if that would be ideal as that manifest.


I guess this all depends a bit on how this all is intended to be used.

Thanks,
Guillem