/cygdrive/c permission denied

/cygdrive/c permission denied

[Mike Brennan]

Hi,

Windows 7.  
uname -a gives: 
   CYGWIN_NT-6.1-WOW64 Dalea 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin

Recently lost ability to do "ls" in directory /cygdrive/c.

   $ cd /cygdrive/c
   $ ls
   ls: reading directory .: Permission denied

This occurred while I was copying a directory (using cpio -p) to /cygdrive/c.
Not sure what went wrong; all was fine before.

When I did "cd /cygdrive; ls -l" I got:

drwx------+ 1 ???????? ???????? 0 Nov 28 17:03 c
drwx------+ 1 SYSTEM SYSTEM   0 Nov 28 16:23 d
drwx------+ 1 SYSTEM SYSTEM   0 Nov 28 16:23 e
drwx------+ 1 SYSTEM SYSTEM   0 Nov 28 16:59 f
drwxr-xr-x  1 psuadm None     0 Jan  1  1980 i

c, d, e, and f are volumes on the two local hard drives.  It is possible
that permissions on "c" were d---------+, not drwx------+; I started changing
things before doing a careful assessment of the initial state.

From the standpoint of Windows security, the owner of C: was (I believe)
TrustedInstaller.  Is that correct, or should it be SYSTEM?

Not sure how I caused this and, once I did, I discovered I don't know
how the heck to fix it.

Any help would be much appreciated.

-Mike


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: /cygdrive/c permission denied

[Warren Young]

On 11/28/2011 5:06 PM, Mike Brennan wrote:
>
> When I did "cd /cygdrive; ls -l" I got:
>
> drwx------+ 1 ???????? ???????? 0 Nov 28 17:03 c

I don't think the ???????? is an error.  I see much the same thing here, 
and I have full read/write access to C:\ via the Cygwin shell.

The only serious difference I see here is that I get "d---------+", so 
going by just that, I shouldn't even be able to cd into it!  C:\ gets 
treated differently by Windows, probably for backwards compatibility 
with DOS or something.  I'm guessing that this prevents Cygwin from 
faking POSIX permission semantics for that directory.

(Don't believe C:\ is special?  Try creating a subdirectory in C:\ while 
UAC is enabled and you're logged in as an Admin.  No UAC dim-out as 
you'd expect when WRITING TO THE FRIGGIN' ROOT DIRECTORY, if the UAC 
hype had anything to do with reality.  Also no complaints when other 
programs write to the directory you just created on your behalf, unlike 
what happens if you try the same thing in, say, c:\PROGRA~1. 
<rolleyes>Windows Security&trade;</rolleyes>)

I'm assuming your cpio -p command overwrote the C:\ ACL with that of the 
top level directory of whatever you were copying.  You may be able to 
fix it with setfacl.  Here's what getfacl says here:

$ getfacl /c
# file: /c
# owner: ????????
# group: ????????
user::---
group::---
group:root:rwx
group:SYSTEM:rwx
group:Users:r-x
mask:rwx
other:---
default:user::---
default:group::---
default:group:root:rwx
default:group:SYSTEM:rwx
default:group:Users:r-x
default:mask:rwx
default:other:---

(Yes, I have cygdrive mounted on / here.  I'm an evil, bad man.  I don't 
think that explains anything, though.)

How you use setfacl to apply any diffs you need there is an exercise 
left to the reader. :)

By the way, if mirroring permissions is what you're after, I'm not sure 
cpio -p is the right thing unless you're copying a directory that 
historically has been managed only via programs built for Cygwin.  I 
dunno, maybe Cygwin's cpio knows all about Windows ACLs and such, and 
doesn't just go by the faked POSIX permissions it gets from stat(2).  I 
do know that such problems plagued Mac OS X for quite a while, and the 
impedance mismatch is much smaller between HFS+ and POSIX filesystem 
semantics than between NTFS and POSIX.  I suggest using robocopy 
instead.  I tend not to prefer native tools, but it'll likely give 
better results in this case.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: /cygdrive/c permission denied

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

On 11/29/2011 08:42 AM, Warren Young wrote:
> The only serious difference I see here is that I get "d---------+", so
> going by just that, I shouldn't even be able to cd into it!

See that + on the end of the mode field?  That means there are ACLs in
affect; and my guess is one of the ACLs allows your uid to change to
that directory even though the owner of the directory does not have the
same permissions.

> $ getfacl /c
> # file: /c
> # owner: ????????
> # group: ????????
> user::---
> group::---
> group:root:rwx
> group:SYSTEM:rwx
> group:Users:r-x

Yep - just as I said.  The actual uid/gid owner (which is probably being
treated as -1 meaning your /etc/group and /etc/passwd are incomplete) is
different than the 'root', 'SYSTEM', or 'Users' groups, all of which
have an additional ACL allowing you to chdir into the directory.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: /cygdrive/c permission denied

[Corinna Vinschen]

On Nov 29 08:51, Eric Blake wrote:
> On 11/29/2011 08:42 AM, Warren Young wrote:
> > The only serious difference I see here is that I get "d---------+", so
> > going by just that, I shouldn't even be able to cd into it!
> 
> See that + on the end of the mode field?  That means there are ACLs in
> affect; and my guess is one of the ACLs allows your uid to change to
> that directory even though the owner of the directory does not have the
> same permissions.
> 
> > $ getfacl /c
> > # file: /c
> > # owner: ????????
> > # group: ????????
> > user::---
> > group::---
> > group:root:rwx
> > group:SYSTEM:rwx
> > group:Users:r-x
> 
> Yep - just as I said.  The actual uid/gid owner (which is probably being
> treated as -1 meaning your /etc/group and /etc/passwd are incomplete)

For system installed dirs, that's typically the "TrustedInstaller"
account, which doesn't match any usual SID scheme.  It's not in
/etc/passwd or /etc/group since mkpasswd/mkgroup don't make any effort
to generate an entry.  Patches welcome.


Corinna

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

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple