Add /etc/xattr.conf in the sandbox to workaround cross-FS copy issue #3754
Conversation
Fixes systemd#3732. This problem is only present when copying files across filesystem boundaries. Caveat: /etc/xattr.conf itself might be copied to destination if present at the source. This should be fine until coreutils bug 78623 is closed.
|
BTW, alternative is to use |
| p.write_text( | ||
| textwrap.dedent( | ||
| """ | ||
| * skip # Default: ignore all xattr but | ||
| system.* permissions # allow well-known 'system' | ||
| trusted.* permissions # allow well-known 'trusted' | ||
| user.* permissions # allow well-known 'user' | ||
| security.* permissions # allow well-known 'security' | ||
| # but | ||
| trusted.SGI_* skip # skip XFS-specific namespace (not portable) | ||
| user.Beagle.* skip # skip Beagle index data (not portable) | ||
| security.evm skip # skip evm (may only be written by kernel) | ||
| """ | ||
| ) | ||
| ) |
There was a problem hiding this comment.
Can we make this a bit smarter and also copy the btrfs attrs if we detect the destination filesystem is also btrfs?
There was a problem hiding this comment.
The only btrfs xattr I know about is btrfs.compression, which is definitely something I think should be set by systemd-repart (Compression=...), not copied over from whatever host configuration is.
Normal file attributes (chattr) are not affected by this barred one: btrfs that calculates the c-flag on the fly depending on btrfs.compression xattr, which we've established is not something we should be copying over anyway.
There was a problem hiding this comment.
Have we established that? I don't remember agreeing to that. If a file is compressed on one btrfs filesystem, why shouldn't it be compressed after copying?
There was a problem hiding this comment.
If a file is compressed on one btrfs filesystem, why shouldn't it be compressed after copying?
Because the one who "chose" to compress it was myself from 7 years ago, not the package manager.
On my system, I, myself, chose to btrfs set property set / compression "zstd", 7 years ago when I installed my local system. And now, this is inherited by mkosi's workspace folder (as xattr btrfs.compression = zstd).
Do we want to persist local arbitrary choices or do we want that choice to be explicit made in repart.d files?
If you want btrfs.compression to be copied, you need to make sure you start with a clean slate (i.e. clean file system) so that you can ensure this was an explicit packaging choice.
There was a problem hiding this comment.
I can make it smarter, but if we do, we might as well make a few checks on a single canary file before copying the tree and use cp -a, which will opportunistically keep as much metadata as possible.
There was a problem hiding this comment.
I see the problem... systemd-repart does not set btrfs.compression. Compression=zstd seems to actually do nothing with btrfs: it's supposed to use a mkfs.btrfs flag to force compression whilst copying files but compsize reports no compression was ever attempted. That definitely is suboptimal. Proof:
Debug shows the same:
root-x86-64 is as generated by systemd-repart with Compression=zstd whereas new-btrfs-root was generated with sudo mkfs.btrfs --compress=zstd -L "new-btrfs-root" -r ".../root-x86-64/" btrfs.img.
Not a bug in mkosi, just a constraint added to a very hairy problem...
Fixes #3732.
This problem is only present when copying files across filesystem boundaries. Caveat: /etc/xattr.conf itself might be copied to destination if present at the source. This should be fine until coreutils bug 78623 is closed.