|
Date: Wed, 22 Jan 2020 22:05:52 +0100 From: Florian Weimer <fweimer@...hat.com> To: Rich Felker <dalias@...c.org> Cc: 39236@...bugs.gnu.org, musl@...ts.openwall.com Subject: Re: coreutils cp mishandles error return from lchmod * Rich Felker: > On Wed, Jan 22, 2020 at 09:48:14PM +0100, Florian Weimer wrote: >> * Rich Felker: >> >> >> Hmm. The way I read the musl code, the O_PATH descriptor already >> >> exists. At this point, you can just chmod the O_PATH descriptor, and >> >> have the kernel report EOPNOTSUPP if the file system does not support >> >> that. >> > >> > Oh, you mean the second one after it's already open? Maybe that's ok. >> >> Yes, that's what I meant. >> >> > I was concerned it might follow the link and chmod the target at that >> > point. >> >> In my tests, it works. I think it's also documented behavior for chown >> on these pseudo-files. > > Do you know where we might find that documentation? Ugh. I'm probably misremembering. It may have been a rejection of patch to implement another f*at system call with AT_EMPTY_PATH support. (I did find your 2013 message describing the chmod and chown behavior.) Thanks, Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.