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, 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?) Rob
