bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?
Paul Eggert <[email protected]>
| Newsgroups | gmane.comp.gnu.core-utils.bugs |
|---|---|
| Organization | UCLA Computer Science Department |
| Message-ID | <[email protected]> |
On 2025-09-16 07:36, Steffen Nurpmeso wrote: > My enthusiasm is hereby extinct Yeah, it's really hard to figure out what went wrong, given that all we have is a stripped executable that may not have be built correctly for whatever reason. One possibility is some low-level problem with the dynamic linker. So you can ignore the rest of this email if you like. > at copy.c:3106 since i see > > unlinkat > readlink@plt > symlinkat@plt > free > lstat@plt [hmm where; lchownat fallback?] It could be from lib/fchownat.c:106, if CHOWN_TRAILING_SLASH_BUG is defined. However, I'd be surprised if this were the case, as glibc doesn't have that bug as far as I know. > lstat64 > fstatat64 > lchown@plt > lchown > > Thereafter only 10 "??" stepi in between resolved lchown and > > lchmod@plt > fchmodat If 'cp' was linked correctly, I don't see any way there could be only 10 insns between resolved lchown (presumably called from src/copy.c:3152 via lib/openat.h:77) and any call to lchmod/fchmodat.