Upstream coreutils provides code for copying moving or installing xattrs if coreutils is built with --enable-xattr. However, the default behavior with cp, mv and install are different: mv: preserves xattrs without any flags cp: preserves xattrs with --preserve=xattr flags install: is hard coded to not copy xattrs This patch consistently makes it so, if USE=xattr is set, then all three utilities will preserve xattrs by default and only with --no-preserve=xattr will they not copy over extended attributes. This is needed for preserving XATTR_PAX flags. Quite a few ebuilds do pax markings before they install thus loosing the flags. In some cases this can be changed, but in others it is more problematic. Reproducible: Always
Created attachment 348680 [details, diff] Preserve extended attributes by default when doing cp, mv or install While this patch is sufficient, we may want to consider the following: 1) I will add documentation once the discussion settles. 2) We can approach this by adding another configure flag, something line --enable-preserve-xattr and push it upstream. I didn't do that because it would require us to autoreconf coreutils in the ebuild. Otherwise I could patch directly against configure? But, I'm not sure upstream would like the idea. In which case we could just conditionally apply this on USE="pax_kernel".
Oh one final point, right now I've got require_preserve_xattr = true, but we may want to relax that and just do preserve_xattr = true so we don't throw an error when xattr's can't be copied.
Can we make sure only the user.* namespace is preserved? The security.* namespace might be a bit more critical for such changes or even might break the system. For instance, SELinux contexts (security.selinux) are known to be preserved on move (mv) but not on copy (cp), which is also expected behavior and documented. Generally, I wouldn't touch the security.* namespace in cp/install: - security.selinux is governed through SELinux policies and install might not have the proper rights to manage SELinux labels - security.evm is managed by Linux kernel, and if at least one security.* isn't "moved" with it then it becomes invalid and the file cannot be opened anymore. It also depends on the other permission sets of the file so changes there also mean change of EVM attribute. - security.ima is managed by Linux kernel and will move with it regardless of implementation - security.SMACK64 is for the SMACK security implementation - security.capability might have a case for preserving
(In reply to comment #3) > Can we make sure only the user.* namespace is preserved? > > The security.* namespace might be a bit more critical for such changes or > even might break the system. For instance, SELinux contexts > (security.selinux) are known to be preserved on move (mv) but not on copy > (cp), which is also expected behavior and documented. > > Generally, I wouldn't touch the security.* namespace in cp/install: > > - security.selinux is governed through SELinux policies and install might > not have the proper rights to manage SELinux labels > - security.evm is managed by Linux kernel, and if at least one security.* > isn't "moved" with it then it becomes invalid and the file cannot be opened > anymore. It also depends on the other permission sets of the file so changes > there also mean change of EVM attribute. > - security.ima is managed by Linux kernel and will move with it regardless > of implementation > - security.SMACK64 is for the SMACK security implementation > - security.capability might have a case for preserving Noted. I can create a list of xattr's to be preserved.
this is something you should be submitting to the upstream coreutils lists. i'm not going to change the default behavior here if upstream doesn't.
(In reply to comment #5) > this is something you should be submitting to the upstream coreutils lists. > i'm not going to change the default behavior here if upstream doesn't. Okay. But to be clear, I was not suggesting changing the behavior for everyone, but only for USE=pax_kernel.
(In reply to comment #6) i'm not sure that nuance is sufficient. if anything, it makes things more confusing.
(In reply to comment #7) > (In reply to comment #6) > > i'm not sure that nuance is sufficient. if anything, it makes things more > confusing. Okay I can see that. Can I ask for some design advise? The basic problem I'm trying to solve is to preserve XATTR_PAX flags when emerging --- these live in the xattr user.pax.flags namespace. To do this, I need "install" to preserve at least those xattrs. What is the best approach? Once I've got a clear plan, I'll do all the coding/pushing upstream etc.
(In reply to comment #8) you can ask for whatever you like ;) the behavior today is that `cp foo bar` doesn't preserve anything. not perms, not ownership, not xattrs (well, not 100% true wrt perms, but close enough). i'm not sure why we would want to special case xattrs in face of this ? this also lines up with how POSIX describes things: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cp.html "The cp utility shall copy the contents of source_file ... to the destination path named by target_file." it then goes on to basically mandate the current behavior (not preserving things). i agree that it'd be nicer if "best effort preserve" was the default behavior, but this is what POSIX has to say on the matter. if people want things preserved, then they need to use the -a or -p flag. iiuc, xattrs will be preserved in that scenario. when it comes to `install`, there is no official spec that i'm aware of. just historical precedence. so you might be able to argue that preserving xattrs with this util doesn't violate specs, but it would violate KISS: mode/ownership setting is clear in how it behaves (it uses defaults unless an explicit command line flag is given), so having it preserve xattrs only by default is weird. the install tool talks about '--preserve-context' wrt selinux ... is that talking about all xattrs, or just selinux specific ones ? if it's just selinux, then that should probably be generalized or a new --preserve option akin to the one in `cp` should be added. so my prognosis might not be what you want to hear, but i'm not an upstream GNU coreutils maintainer, so i could be completely wrong. they have a general discussion list where you can post your ideas and get official guidance: https://lists.gnu.org/mailman/listinfo/coreutils
