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

[Gael Donval]

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.

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).

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. :)

Gaël


> 
> > 
> > Would it make sense then to do what tar does and blindly serialize
> > (and
> > expose) everything and provide a --xattrs-exclude=pattern in case
> > people want something more fine-grained?
> 
> As I said above.
> 
> Thanks,
> Gao Xiang
> 
> > 
> > The only main problem currently is that erofs tries to be smart
> > about
> > xattrs and errors out when it does not know about something. It
> > should
> > really be more graceful.> 
> > Thanks,
> > Gaël
> > 
> > 
> > > 
> > > Thanks,
> > > Gao Xiang
> > > 
> > > > 
> > > > Gaël
> > > > 
> > > > > 
> > > > > Thanks,
> > > > > Gao Xiang
> > > > > 
> > > > > > Thanks for your help,
> > > > > > Gaël
> > > > > > 
> > > > > > 
> > > > 
> >