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

Corinna Vinschen corinna-cygwin@cygwin.com
Mon Nov 30 11:03:44 GMT 2020


On Nov 28 22:59, Christian Franke wrote:
> There a very few but occasionally interesting use cases for read access to
> block devices below /proc/sys:
> 
> - Read raw images behind drive letters which are not linked to regular
> /dev/sdXN partitions. For example read decrypted images of VeraCrypt
> partitions or container files:
> /proc/sys/DosDevices/X: -> /proc/sys/Device/VeraCryptVolumeX
> 
> - Read raw images of Volume Shadow Copies:
> /proc/sys/Device/HarddiskVolumeShadowCopy*
> 
> Copying such an image actually works with 'dd', but 'ddrescue' reports a non
> seekable device. This is because fhandler_virtual::lseek() is used. It calls
> fhandler_procsys::fill_filebuf() which does not make any sense in this
> context. This lseek() always fails - without setting errno, BTW.
> 
> 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?


Thanks,
Corinna


More information about the Cygwin-patches mailing list