GNU bug report logs - #79433
9.7: cp(1): lchownat(2/3) fallback bogus?

Previous Next

Full log

Message #53 received at 79433 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Steffen Nurpmeso <steffen <at> sdaoden.eu>
Cc: 79433 <at> debbugs.gnu.org
Subject: Re: bug#79433: 9.7: cp(1): lchownat(2/3) fallback bogus?
Date: Tue, 16 Sep 2025 12:07:42 -0700

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 <at> plt
> 	symlinkat <at> plt
> 	free
> 	lstat <at> 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 <at> plt
> 		lchown
> 
> Thereafter only 10 "??" stepi in between resolved lchown and
> 
> 	lchmod <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.