Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.