Cygwin for Windows 8

Corinna Vinschen
Wed Oct 17 09:51:00 GMT 2012

On Oct 17 09:03, GrahamC wrote:
> On Oct 16 Corinna Vinschen wrote:
> > On Oct 15 23:55, GrahamC wrote:
> > > Another anomaly with disk drive partition devices (/dev/sdX1, /dev/sdX2 etc.) is the access control.
> > >  
> > > While the whole disk devices (/dev/sdX) can only be accessed when running as administrator, the
> > > individual partition devices (/dev/sdX1, /dev/sdX2 etc.) can be both read and written without
> > > needing administrator mode.
> >
> > Access control is not done inside Cygwin.  The permissions on the block
> > devices are set by Windows.  If you want to take a closer look,  see
> > the mapping of the native namespace into the Cygwin /proc/sys namespace.
> > Look at everything under /proc/sys/Device/Harddisk*, but make sure you're
> > admin, otherwise you won't see everything.  If you want to take an even
> > closer look, I suggest to download the winobj tool from sysinternal.  It
> > also provides a detailed ACL view.
> >
> > Device creation is based on what Windows creates. Cygwin only looks
> > which devices exist in the internal native namespace and maps those to
> > the equivalent POSIX device names.  If a \Device\HarddiskX\PartitionY
> > exists, then /dev/sd<X>Y exists in Cygwin, with <X> being 'a' + X.
> >
> > As for the missing ~70 sectors, I'm not sure.  How do you know?  Does
> > the number of KBs you can read differ by this amount from the KBs given
> > in /proc/partitions?  
> >
> > Maybe that's the missing call to FSCTL_ALLOW_EXTENDED_DASD_IO.  Cygwin's
> > block device code only calls this Windows ioctl code for full disks, not
> > for partitions on the disk.  I fixed that in CVS, though.  Can you give
> > the today's snapshot from a try, please?
> OK, the 20121016 snapshot of cygwin1.dll fixed the data truncation 
> problem. The number of sectors readable from the /dev/sdXY 
> devices now match the partition sizes.

I'm very glad to read that.

> My missing partition devices appears to be an incompatibility between
> the Linux parted tool and Windows. The former puts a 6 byte disk ID in the
> partition sector at position 0x1b8..0x1bd, Windows uses the first 4 bytes only
> and if two disks have the same value it doesn't create volumes for the second disk. 
> Patching the ID to a unique value in the first 4 bytes made the missing partitions
> appear at next boot up. 

In theory you should be able to get away without reboot.  There's
a diskpart command available since at least XP.  Diskpart knows a
"rescan" command, which tells the OS to rescan the disks and see
if anything changed.

> Non-administrator read and write access to /dev/sdXY devices appears to 
> be limited to the USB flash devices.

Yeah, I had a hunch that it was related to the disk type (fixed vs.

>  The WinObj tool shows the 
> group INTERACTIVE having read and write access to these. I suppose this 
> makes sense from the Windows point of view. WinObj also shows group 
> Everyone has read access to the raw disk devices DR0, DR1, DR2 etc., 
> but that doesn't seem to make it through to the /dev/sdX devices (not 
> that I would want it to).

Yes, that puzzled me as well, but it makes sense.

The ACL information given in winobj is not as detailed as I had hoped
for.  In fact, "Everyone" only has READ_CONTROL and FILE_READ_ATTRIBUTE
permissions, but *not* FILE_READ_DATA.  If you try to open anything for
reading, Cygwin requests GENERIC_READ permissions which obviously
includes FILE_READ_DATA permissions as well.  Naturally, that fails with

So, in fact a non-admin can get meta information about a block device
(think "stat"), but can not open the device for reading.  And,
surprisingly, this time the Cygwin information is more correct than the
winobj information:

  $ ls -l /proc/sys/Device/Harddisk0/DR0
  brwxrwx--x 1 Administrators SYSTEM 0, 250 Oct 17 11:49 /proc/sys/Device/Harddisk0/DR0

As you can see, no read permissions for "Other"


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list