Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Fri, 21 Jan 2005 13:04:11 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: file name inconsistencies
Message-ID: <20050121120411.GO3113@cygbert.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <41F082E9 DOT 6060702 AT byu DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41F082E9.6060702@byu.net>
User-Agent: Mutt/1.4.2i

On Jan 20 21:19, Eric Blake wrote:
> Second, cygwin does not conform to POSIX when performing pathname
> resolution.  POSIX requires, in
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11
> and in many of the syscalls, that the call fail if any component of the
> pathname is inaccessible.  For example, stat() is required to fail with
> EACCES if search permission is denied for any component of the path
> prefix, but this example shows that cygwin is succeeding:
> $ cd /tmp
> $ mkdir d d/d1
> $ chmod 0 d
> $ touch d/d1/f # should fail, d is inaccessible
> $ ls d/d1 # should fail, d is inaccessible
> f
> $
> 
> However, this may be a bug in the underlying Windows OS.  I opened up
> Windows explorer, then browsed to the location of /tmp.  Clicking on d
> gives "C:\cygwin\tmp\d is not accessible. Access is denied."  But going to
> the address bar, and typing in c:\cygwin\tmp\d\d1 browses right to that
> supposedly inaccessible nested directory!  Is it worth fixing cygwin to
> reject paths to comply with POSIX, when Windows can still access such
> paths?  Or is there something wrong in the ACL manipulation going on with
> `chmod 0', so that it is not really stripping all access rights?

We (the Cygwin developers) discussed this already long ago and came to the
conclusion that it's not worth the hassle.

Actually it's not a Windows bug, but a feature.  NT knows about a user
right called "Bypass traverse checking", SeChangeNotifyPrivilege, which
is given to all users by default.  This is the right, which allows a
user to access all files with a matching ACL, without checking the
parent folders.

What you should be able to do (but which I never tested myself) is, to
remove this right from your own process, so that this process works
automatically under POSIX access rules.

The problem is that we can't do this in Cygwin without asking for a lot
of trouble.  We don't know how people manage their system, resp. how their
admins manage their system.  I can easily imagine that after doing this
automatically in Cygwin, Cygwin applications don't work anymore on 50%
of the installations.  I'm not sure if I really want that :-)

> Finally, is there any reason that `df --local' cannot find any local
> filesystems?  It is rather odd to see the coreutils testsuite skip tests
> because there is no local filesystem that it can find, when I know for a
> fact that my machine has a local hard-drive at c:\.

Debugging helps.  See coreutils/lib/mountlist.h

  #ifndef ME_REMOTE
  /* A file system is `remote' if its Fs_name contains a `:'
     or if (it is of type smbfs and its Fs_name starts with `//').  */
  # define ME_REMOTE(Fs_name, Fs_type)    \
      (strchr ((Fs_name), ':') != 0       \
       || ((Fs_name)[0] == '/'            \
	   && (Fs_name)[1] == '/'         \
	   && STREQ (Fs_type, "smbfs")))
  #endif


Corinna

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

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