This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: Message Nav: [Date Index] [Subject Index] [Author Index] [Thread Index] [Date Prev] [Date Next] [Thread Prev] [Thread Next] [Raw text]

# Re: file name inconsistencies

• From: Corinna Vinschen <corinna-cygwin at cygwin dot com>
• To: cygwin at cygwin dot com
• Date: Fri, 21 Jan 2005 13:04:11 +0100
• Subject: Re: file name inconsistencies
• References: <41F082E9.6060702@byu.net>
• Reply-to: cygwin at cygwin dot com

```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