[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cygwin-patches
Subject:    Re: [PATCH] Cygwin: Fix access to block devices below /proc/sys.
From:       Corinna Vinschen <corinna-cygwin () cygwin ! com>
Date:       2020-11-30 14:21:23
Message-ID: 20201130142123.GI303847 () calimero ! vinschen ! de
[Download RAW message or body]

On Nov 30 15:04, Corinna Vinschen wrote:
> On Nov 30 13:49, Christian Franke wrote:
> > Corinna Vinschen wrote:
> > > On Nov 28 22:59, Christian Franke wrote:
> > > > ...
> > > > The attached experimental patch does not fix the lseek() (sorry), but
> > > > handles such block devices with fhandler_dev_floppy instead. Tested with
> > > > above use cases.
> > > > 
> > > > I'm not sure whether this could break access to other /proc/sys block
> > > > devices. This would happen if fh->exists() returns virt_blk for devices
> > > > which do not support IOCTL_DISK_GET_DRIVE_GEOMETRY* or
> > > > IOCTL_DISK_GET_PARTITION_INFO*.
> > > Pushed, becasue it's a nice idea.  The above problem shouldn't happen,
> > > in theory, but I'm not sure.  virt_blk is generated for devices types
> > > 
> > > FILE_DEVICE_DISK
> > > FILE_DEVICE_CD_ROM
> > > FILE_DEVICE_VIRTUAL_DISK
> > > FILE_DEVICE_DFS
> > > FILE_DEVICE_NETWORK_FILE_SYSTEM
> > > 
> > > FILE_DEVICE_DFS or FILE_DEVICE_NETWORK_FILE_SYSTEM might be a problem,
> > > but there should be a way to workaround that, if necessary, isn't it?
> > > Maybe it's a bad idea to treat those as blk devices at all?
> > 
> > Could anything be read from such a node? If yes, treat as character device?
> > 
> > If no and /proc/sys/foo/bar/some/path allows access to /some/path behind
> > DFS/NFS node /proc/sys/foo/bar, then treat as directory?
> > 
> > This is already the case for SMB shares:
> > 
> > $ ls -ld /proc/sys/DosDevices/X:
> > lr-------- 1 ... 0 Nov 30 13:10 /proc/sys/DosDevices/X: ->
> > /proc/sys/Device/LanmanRedirector/;X:..../127.0.0.1/Share
> > 
> > $ ls -lLd /proc/sys/DosDevices/X:
> > drwxr-xr-x 1 ... 0 Nov 14 09:06 /proc/sys/DosDevices/X:
> > 
> > $ ls -L /proc/sys/DosDevices/X:
> > ... files on this share
> 
> ...and it's already the case for NFS shares, too:
> 
> $ ls -ld /proc/sys/DosDevices/Y:
> lr-------- 1 corinna vinschen 0 Nov 30 14:59 /proc/sys/DosDevices/Y: -> \
> /proc/sys/Device/MRxNfs/;Y:00000000001cb27f/... 
> $ ls -lLd /proc/sys/DosDevices/Y:
> drwxr-xr-x 5 corinna vinschen 41 May 19  2016 /proc/sys/DosDevices/Y:
> 
> That means we don't have to handle FILE_DEVICE_NETWORK_FILE_SYSTEM in
> the code creating the virt_blk device type at all.  I have high hopes
> this is the same for DFS, albeit I can't test it...

Oh, right, I just realized that \Device\MRxNfs, as well as
\Device\LanmanRedirector are symlinks pointing below \Device\Mup:

$ ls -l /proc/sys/Device/LanmanRedirector
lr--r--r-- 1 Administrators SYSTEM 0 Nov 30 15:20 /proc/sys/Device/LanmanRedirector \
-> /proc/sys/Device/Mup/;LanmanRedirector

$ ls -l /proc/sys/Device/MRxNfs
lr--r--r-- 1 Administrators SYSTEM 0 Nov 30 15:20 /proc/sys/Device/MRxNfs -> \
/proc/sys/Device/Mup/;MRxNfs

\Device\Mup is a character device and thus the devices below are not
accessible for directory enumeration.  I assume it's the same for DFS.


Corinna


[prev in list] [next in list] [prev in thread] [next in thread]