> Perhaps you can fix
this by fixing the Link sections of the relevant modules to use
$(LIB_HAS_ACL) instead of $(LIB_ACL). That is, for each module where you
added $(LIB_XATTR), replace its $(LIB_ACL) with $(LIB_HAS_ACL) if the
only reason it needed $(LIB_ACL) was to copy attributes.
Nope. LIB_HAS_ACL has value only if glibc does not know getxattr() system call. It has nothing to do with libattr (yes, it's bit confusing).
Why don't we solve the linker problem with the "--as-needed" option? This will make linker clever enough not to link libraries that are not needed.
> Also, come to think of it, is there a security issue between the
chmod_or_fchmod call, and the attr_copy_fd call? That is, could the file
temporarily be set to too-generous permissions, between the two calls? A
comment explaining this issue would help.
It depends on a kernel ACL implementation. On Linux the ACLs make the permissions only more opened (hence my code would be fine).
In contrast, on Solaris/ZFS, the opposite could happen.
NetApp NFSv4 server even allows you to break RFC7530 the way that chmod 0 <file> will still allow the inherited ACLs to be applied.
In general, I'd say we should be secure here.