[PATCH 0/3] Some O_PATH fixes
Wed Jan 29 09:52:00 GMT 2020
On Jan 29 03:08, Ken Brown wrote:
> 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?
The handle is a pipe handle, not the file handle, and the permissions
on the pipe handle were not reflecting the permissions on the file.
The NULL pointer was trying to make sure that the file gets opened
for fetching the security descriptor in get_file_sd().
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Cygwin-patches