11.03.2025 14:54, Cornelius Hoffmann wrote:
Package: postfix
Version: 3.10.1-1
Severity: important
Hi,
I'm facing an issue on a ephemeral machine booted into a read-only nfs4
root with an overlayfs to make / writable. postfix doesn't start, since
the copy command in configure-instance:91 fails. It copies the data, but
overlayfs has an long-standing issue with nfs4_acls [1], which cp -p will
try to copy but fail.
Why it fails? From the cp(1) manpage:
-p same as --preserve=mode,ownership,timestamps
This list looked innocent enough to keep everything. Which ACLs it tries
to copy here? It shouldn't?
--preserve[=ATTR_LIST]
preserve the specified attributes (default: mode,ownership,time‐
stamps), if possible additional attributes: context, links,
xattr, all
Even with --preserve (with no argument, which is different from -p), it
*tries* to preserve additional attributes only "if possible".
I'm confused. Mode, ownership and timestamp has always been copied by
this code (it used cpio in the past). Maybe cp(1) does more than what's
described, - in which case it definitely should be fixed one way (by
removing extra actions it does) or another (fixing the docs to match
reality).
And I really don't want to remove -p from there. I'd use --preserve
(without arg) for it to copy context too, *if possible*. Because else
there will be complains that postfix allows too wide access to the
system files someone hardened on their system.
(BTW, using cp(1) here is wrong due to a different reason, - the -u
option, - once we've a file in chroot which is more recent, reverting
back to old version - eg, downgrading a package - doesn't work anymore).
The files are thus copied over and on the next
start of postfix, the service will start without any issues (complaing
again about the same problem for copying the libraries in Line 109, which
is ignored though by the trailing || : in this line.
Is there a specific reason to copy these files with -p? From what I can
tell, they're all word-readable and owned by root:root, so maybe
preserving timestamps (if that is intended) would be enough? From the
commit introducing -p [2], It seems like this was done to have more
readable code.
That would solve this issue for this specific scenario without
interfering with other installations as far as I can tell.
I acknowledge that this should ideally be fixed in overlayfs for a
general solution, but in hope of getting a faster solution, I wanted to
ask if you'd consider changing the cp options.
It's an interesting idea, I definitely see your intention here, and
definitely sympathize. Yet, I'd love to understand what's going on
here, if not only for documentation purposes. Current solution seems
to be the best one..
Thanks,
/mjt
