On 12/02/2020 13:07, Rich Felker wrote: > On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote: >> On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote: >>> * Paul Eggert: >>> >>>> On 1/22/20 2:05 PM, Rich Felker wrote: >>>>> I think we're approaching a consensus that glibc should fix this too, >>>>> so then it would just be gnulib matching the fix. >>>> >>>> I installed the attached patch to Gnulib in preparation for the upcoming >>>> glibc fix. The patch causes fchmodat with AT_SYMLINK_NOFOLLOW to work on >>>> non-symlinks, and similarly for lchmod on non-symlinks. The idea is to >>>> avoid this sort of problem in the future, and to let Coreutils etc. work >>>> on older platforms as if glibc 2.32 (or whatever) is already in place. >>> >>> The lchmod implementation based on /proc tickles an XFS bug: >>> >>> >> >> Uhg, why does Linux even let the fs driver see whether the chmod is >> being performed via a filename, O_PATH fd, or magic symlink in /proc? >> It should just be an operation on the inode. > > OK, I don't think it's actually clear from the test that the use of > the magic symlink is the cause. It's plausible that XFS just always > returns failure on success for this operation, and I don't have XFS to > test with. My root fs is XFS, but I only have musl to test with. Is there a test case I can run on musl to determine the behaviour of XFS for you? The only glibc distribution that supports my platform is Void, so I don't know if the Void glibc spin in a chroot would be sufficient if there is no way to do this from a musl system. Best, --arw -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org