[PATCH] Cygwin: Fix access to block devices below /proc/sys.

Christian Franke Christian.Franke@t-online.de
Tue Dec 1 15:59:04 GMT 2020


Corinna Vinschen wrote:
> 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.


Here I see \Device\Mup as a block device on two systems (cygwin1.dll 3.1.7):

$ ls -l /proc/sys/Device/Mup
brwxrwx--x 1 Administrators SYSTEM 0, 250 Dec  1 16:50 /proc/sys/Device/Mup

Device could be opened for reading, but actual read fails with NTSTATUS 
STATUS_INVALID_DEVICE_REQUEST.

Any path which do not exist produce misleading results:

$ ls -l /proc/sys/Device/Mup/no.such.file
crw-rw---- 1 Administrators SYSTEM 0, 250 Dec  1 16:52 
/proc/sys/Device/Mup/no.such.file


Thanks,
Christian



More information about the Cygwin-patches mailing list