On 11/26/2018 6:42 PM, Rob Landley wrote:
On 11/26/18 6:56 AM, Roberto Sassu wrote:
On 11/23/2018 9:21 PM, Rob Landley wrote:
The aim of this patch is to provide the same functionality without
introducing a new format. The value of xattrs is placed in regular files
having the same file name as the files xattrs are added to, plus a
separator and the xattr name (<filename>.xattr-<xattr name>).
I think you're solving the wrong problem, but that's just my opinion.
Instead of iterating over rootfs, would it be better to detect files
with extended attributes (from the file name) when the cpio image is
parsed by the kernel,
Huh, I thought at first glance that's what the new approach _was_ doing.
In band signaling in the archive is ugly, still requires new tools to create it,
For SElinux, the changes would be minimal. Instead of adding the
xattr, setfiles would create a regular file with the suffix, in the
temporary directory containing the files to be added to the CPIO image.
For IMA, I think there is also a tool to write file signatures. It
shouldn't be a problem to do the same modification I proposed for
SELinux.
doesn't address the y2038 issue... (Although we could cheat, treat the time
signature as unsigned, and buy another few decades.)
But doing that in the filesystem _after_ you extract the archive is beyond ugly.
and call sys_lsetxattr() in do_copy()? This part
can be turned on by introducing a new type in the existing format (if
possible).
The impact of this alternative is very low, and LSMs/IMA would be able,
with minimum effort, to enforce policies on files in the initial ram
disk.
The cpio extension isn't a big deal, I was pondering doing it myself in toybox
(and submitting a kernel patch to consume the output) before Mimi approached me.
(I did the initmpfs stuff already, I've stomped around in this area before.) I
just didn't because mimi sent their patch first, so I waited for that to work
its way though.
Unfortunately, it's simple enough that there was a bit of bikeshedding. (You can
store time in milliseconds as a 64 bit number without worrying about the range,
but if you do it as nanoseconds you need two fields, but people spoke up and
said "but if you don't store the nanoseconds the rounding causes spurious time
differences when between filesystems and it confuses our build system about what
has and hasn't changed"...)
The new in-band signaling proposal is, at best, a hack. (Filename lengths are
capped at 255 in the VFS, can you strip the xattrs on a long filename by having
the extension fail to create in the filesystem? Or do you have an arbitrary max
length on filenames because you need to reserve room for the extension?)
Yes, that would be a limitation. Alternatively, files with xattrs could
be placed in a subdir. For example:
/bin/cat
/bin/.xattr-<xattr name>/cat
Roberto
Rob
--
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Jian LI, Yanli SHI
