[PATCH v3 2/2] initramfs: introduce do_readxattrs()
hpa at zytor.com
hpa at zytor.com
Wed May 22 16:18:36 UTC 2019
On May 17, 2019 7:16:04 PM PDT, Rob Landley <rob at landley.net> wrote:
>On 5/17/19 4:41 PM, H. Peter Anvin wrote:
>> On 5/17/19 1:18 PM, hpa at zytor.com wrote:
>>> Ok... I just realized this does not work for a modular initramfs,
>composed at load time from multiple files, which is a very real
>problem. Should be easy enough to deal with: instead of one large file,
>use one companion file per source file, perhaps something like
>filename..xattrs (suggesting double dots to make it less likely to
>conflict with a "real" file.) No leading dot, as it makes it more
>likely that archivers will sort them before the file proper.
>>> A side benefit is that the format can be simpler as there is no need
>to encode the filename.
>>> A technically cleaner solution still, but which would need archiver
>modifications, would be to encode the xattrs as an optionally nameless
>file (just an empty string) with a new file mode value, immediately
>following the original file. The advantage there is that the archiver
>itself could support xattrs and other extended metadata (which has been
>requested elsewhere); the disadvantage obviously is that that it
>requires new support in the archiver. However, at least it ought to be
>simpler since it is still a higher protocol level than the cpio archive
>>> There's already one special case in cpio, which is the
>"!!!TRAILER!!!" filename; although I don't think it is part of the
>formal spec, to the extent there is one, I would expect that in
>practice it is always encoded with a mode of 0, which incidentally
>could be used to unbreak the case where such a filename actually
>exists. So one way to support such extended metadata would be to set
>mode to 0 and use the filename to encode the type of metadata. I wonder
>how existing GNU or BSD cpio (the BSD one is better maintained these
>days) would deal with reading such a file; it would at least not be a
>regression if it just read it still, possibly with warnings. It could
>also be possible to use bits 17:16 in the mode, which are traditionally
>always zero (mode_t being 16 bits), but I believe are present in most
>or all of the cpio formats for historical reasons. It might be accepted
>better by existing implementations to use one of these high bits
>combined with S_IFREG, I dont know.
>> Correction: it's just !!!TRAILER!!!.
>We documented it as "TRAILER!!!" without leading !!!, and that its
>purpose is to
>That's what toybox cpio has been producing. Kernel consumes it just
>checked busybox cpio and that's what they're producing as well...
Yes, TRAILER!!! is correct. Somehow I managed to get it wrong twice.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the Linux-security-module-archive