[PATCH 0/3] Some O_PATH fixes
Ken Brown
kbrown@cornell.edu
Wed Jan 29 03:08:00 GMT 2020
On 1/28/2020 3:48 PM, Ken Brown wrote:
> On 1/28/2020 2:01 PM, Ken Brown wrote:
>> On 1/28/2020 12:06 PM, Corinna Vinschen wrote:
>>> On Jan 27 13:21, Ken Brown wrote:
>>>> Ken Brown (3):
>>>> Cygwin: fhandler_base::fstat_fs: accomodate the O_PATH flag
>>>> Cygwin: fhandler_disk_file::fstatvfs: refactor
>>>> Cygwin: FIFO::fstatvfs: use our handle if O_PATH is set
>>>>
>>>> winsup/cygwin/fhandler.h | 1 +
>>>> winsup/cygwin/fhandler_disk_file.cc | 24 +++++++++++++++++-------
>>>> winsup/cygwin/fhandler_fifo.cc | 8 ++++++++
>>>> 3 files changed, 26 insertions(+), 7 deletions(-)
>>>>
>>>> --
>>>> 2.21.0
>>>
>>> Patches are looking good to me.
>>
>> OK, I'll push them.
>>
>>> As outlined on IRC, I found a problem with the ACLs created on new
>>> FIFOs and frixed that (I think). However, Cygwin doesn't actually
>>> return the real permissions in stat(), only the constant perms 0666,
>>> kind of like for symlinks. I didn't have time to look into that yet,
>>> but it would be great if we could fix that, too.
>>
>> I'll take a look if you don't get to it first.
>
> Two quick thoughts, and then I won't have time to think about this any more
> until tomorrow:
>
> First, I wonder why in fstat_fs we're not using the stat handle (i.e., pc.handle()).
Ignore this. I was confused.
> Second, in the call to get_file_attribute in fstat_helper
> (fhandler_disk_file.cc:478), why do we set the first argument to NULL instead of
> using our handle?
>
> In both cases I don't immediately see a connection with the permissions problem,
> but it seems inefficient and makes the code confusing. I might well be missing
> something, however.
>
> Ken
>
More information about the Cygwin-patches
mailing list