bug#78623: cp --preserve=xattr copies attr as well as xattr which breaks cross-FS copy

On Fri, 2025-05-30 at 10:16 -0700, Paul Eggert wrote:
> On 2025-05-30 02:37, Pádraig Brady wrote:

>> Note `cp -a` will attempt to copy all xattrs
>> but ignore "operation not supported" errors.

I wasn't aware of this. `cp -a --no-preserve=...` would solve the issue
but I'm pretty positive the tool is coded the way it is specifically to
catch errors. 

Mkosi is made to craft OS images: it should error out if important
xattrs are left out, just like it should error out if `--preserve=mode`
failed: you don't want to figure out your booted system is entirely
UID=0 with perm 777, do you? :) 

> > we only have this issue with --preserve=xattr which diagnoses any 
> > issues.
> > Perhaps we would benefit from a --preserve=supported-xattr option?
> 
> If we go that route, it might be a bit better if the new option-arg 
> began with 'xattr' rather than ended with 'xattr' so that it's easier to 
> find in the doc. Perhaps something like --preserve='xattr-try'?

We are looking for the diagnostics unfortunately.

At this stage, I have no doubt this issue is not a bug. But in terms of
user experience, sorting this out without having to alter a system-wide
static admin-only file would be awesome! (especially when your user is
unprivileged)

> 
> I'm not quite seeing the motivation, though. Why are scripts using 
> --preserve=xattr rather than the much-simpler '-a'? That is, why 
> preserve xattr but not other metadata?

I simplified for the MWE, mkosi actually preserves more than that:

https://github.com/systemd/mkosi/blob/main/mkosi/tree.py#L111-L117

Ideally, we would come up with a `xattr-portable` set of rules to cover
system, user, trusted and security namespaces (and skip the well-known
exceptions to them) but if xattrs are too messy for that, providing a
filtering option that normal users can use without too much gymnastics
would be a great improvement.

Best,
Gaël