mkfs.erofs fails (failed to build shared xattrs, err 61)

[Gao Xiang]

On 2024/3/12 23:29, Gael Donval wrote:
> On Tue, 2024-03-12 at 22:15 +0800, Gao Xiang wrote:
>>
>>
>> On 2024/3/12 21:14, Gael Donval wrote:
>>> On Tue, 2024-03-12 at 20:43 +0800, Gao Xiang wrote:
>>>>
>>
>> ...
>>
>>>> Yes, but that needs a new version (maybe erofs-utils 1.8) though.
>>>
>>> Of course!
>>>
>>>>
>>>> Also I'm not sure how tar --xattrs works for "btrfs.compression",
>>>> does it also work in a relaxed mode? Could you give more inputs
>>>> & tries with "tar --xattrs"?
>>>
>>> Tar just stores XATTRS as their own field. When I
>>>
>>>      $ tar --xattrs -cf foo.tar foo
>>>
>>> and inspect the tar file it appears XATTRS are stored as arbitrary
>>> SCHILY attributes:
>>>
>>>     
>>> ./PaxHeaders/foo0000644000000000000000000000020114574033222010776
>>>      xustar0030 mtime=1710241426.458097911
>>>      30 atime=1710241426.458097911
>>>      30 ctime=1710241426.458097911
>>>      39 SCHILY.xattr.btrfs.compression=zstd
>>>      foo/0000755000175000017500000000000014574033222011551
>>>      5ustar00gdonvalgdonval
>>>      [...]
>>>
>>> So tar blindly serializes everything.
>>>
>>>
>>>>
>>>>>
>>>>> Is there anything the BTRFS people could do to make their FS
>>>>> easier
>>>>> to
>>>>> work with?
>>>>
>>>> Nope, I think it's unrelated to BTRFS but such xattrs are almost
>>>> meaningless for EROFS to keep (since they are their own xattrs.)
>>>
>>> Ah that's interesting.
>>>
>>> I suspect that in this instance the xattrs would not be useful at
>>> all
>>> but other components like SELinux uses xattrs to perform MAC and
>>> who
>>> knows what other xattrs-based schemes exist out there...
>>
>> EROFS will keep common xattrs like selinux, but EROFS doesn't keep
>> btrfs. namespace (or other arbitrary xattr namespaces) like other
>> filesystems like ext4, xfs, f2fs, squashfs, etc.  EROFS only supports
>> "user.", "trusted." and some "system." domains.  In other words, If
>> EROFS has its own xattr namespace, I think other fses won't support
>> "erofs." too, also see:
>>
>> https://urldefense.com/v3/__https://lore.kernel.org/r/20230420092739.75464-1-o451686892@gmail.com__;!!PDiH4ENfjr2_Jw!BWdmKT7HAVU-ujqneKbEcblL0CJC9FhQ-MzikSN038KjlQ7HQqdbv1GpOtpZsBRAoW538RPHVpH3-kL7C5DrJV1lzJbQ_uScdQ$
>>   [lore[.]kernel[.]org]
>>
>> Because that is simple, you don't even know if the content in some
>> arbitrary namespace is static or dynamic.  Or if it has some security
>> issue to keep them.
> 
> I don't think supporting 3rd-party FS is the question here at all. If
> `btrfs.compression=zstd` is set, I don't expect erofs to do anything
> about it. No support. No understanding of what it is about even. Just
> that there is metadata there erofs ignores.

For `btrfs.compression=zstd`, yes, but for many many other unknown
xattrs, that is no.  And since EROFS can be directly mounted, it's not
a good idea to show special xattrs owned by other filesystems.

> 
> The real question is more: does it matter, security-wise, if
> `btrfs.compression=zstd` is added as metadata (just like it is added in
> tar)?
> 
> If there is no harm, there could be an argument to keep them as pure
> metadata (that erofs does NOT act on! no support).

You could try to extract this to ext4/xfs.  I guess `tar` may print
something, but I don't know.

> 
> If there is harm, mkfs.erofs should strip anything that it does not
> support without producing an error.
> 
> Either way, there should be no error. :)

Fair enough, I think I will do this for erofs-utils 1.8, but I tend
to consider unsupported xattr namespaces as warn messages, users
could silence these with proper '-d' message levels.

Thanks,
Gao Xiang