Paul Eggert wrote:
> I see a problem in linking. With this change, programs using the
> qcopy-acl module will link to both $(LIB_ACL) and $(LIB_XATTR), even
> though they do not need to link with $(LIB_ACL). Perhaps you can fix
> this by fixing the Link sections of the relevant modules to use
> $(LIB_HAS_ACL) instead of $(LIB_ACL).
Good point.
But I would call this variable $(COPY_ACL_LIB). Our convention for these
variables is generally
- $(LIBFOO) or $(LIB_FOO) for the library -lfoo (or empty if nonexistent
or not needed),
- $(MODULE_LIB) for the libraries needed by a given module. For example,
we have
$(GETADDRINFO_LIB)
$(GETHOSTNAME_LIB)
$(GETLOADAVG_LIBS)
$(INET_NTOP_LIB)
$(PTY_LIB)
$(YIELD_LIB)
> 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?
For the use of qcopy_acl by copy-file.c, there is no issue, because when
qcopy_acl gets called, the new file has mode 0600 and the owner and group
are already set. So, this is not too generous.
But for the uses of copy_acl in coreutils, I can't really tell...
Bruno
