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


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

Re: CMD.EXE able to create files in directories on a shared drive, but bash in cygwin is unable to


On May 13 15:42, EXCOFFIER Denis wrote:
> Hello,
> 
> This one is a follow-up for http://cygwin.com/ml/cygwin/2011-05/msg00183.html
> 
> On 2011-05-12 09:47:15 -0600 Keith Christian wrote:
> >This permissions problem has existed for awhile, and I'd like to find
> a solution.
> Same for me.
> 
> >CMD.EXE is able to create files inside directories on a standard
> >Windows share, but from a Bash shell on Cygwin, a permission denied
> >message occurs, and this is in most if not all directories:
> Same for me. I use tcsh.
> 
> jupiter% uname -a
> CYGWIN_NT-5.1 TOLX300043890 1.7.10s(0.244/5/3) 20110510 19:08:34 i686 Cygwin
> jupiter%
> 
> (I use the last snapshot)
> 
> 
> =======CMD.EXE=======
> S:\historic>cacls S:\historic
> S:\historic DT\AMNO:(OI)(CI)F
>             <Account Domain not found>(OI)(CI)R
>             <Account Domain not found>(OI)(CI)C
> [...]
> And the strace is similar, with the same requested access bits.
> 
> jupiter% strace -o /tmp/bash.trace bash -c 'echo foo2 > foo2'
> jupiter% grep 'open: C0000022' /tmp/bash.trace
>    65  126396 [main] bash 5412 fhandler_base::open: C0000022 =
> NtCreateFile (0x0, 40160080, \??\S:\historic\foo2, io, NULL, 80, 7,
> 5, 4020, NULL, 0)
> 
> [...]
> and in bash.trace3:
> 49  150149 [main] bash 4948 fhandler_base::open: 0 = NtCreateFile
> (0x650, 40120080, \??\S:\historic\foo, io, NULL, 80, 7, 5, 4020,
> NULL, 0)
> 
> The flag WRITE_DAC has disappeared in these cases.
> 
> So it seems we have to dig into WRITE_DAC.

Ok, so, here's the problem.  The WRITE_DAC permission is requested if
and only if

- the underlying file system supports ACLs, and
- the underlying Cygwin mount point is set to "acl", and
- the file does not exist yet.

The reason to do that is that under the above condition we have
to write the file DACL to set correct POSIX permissions.  In former
versions of Cygwin there was a bug in that the WRITE_DAC permission
was not requested.  This in turn required to open a second handle
to the file just to set the file permissions correctly.  However,
since the success of the function writing the POSIX permissions is
not tested, the open() function succeeded even though the permissions
of the file couldn't be set.  With the latest Cygwin this is not the
case anymore.  If you don't have the right to set permissions, the
file open will fail entirely.

Now, keep in mind that this affects only "acl" mount points.

For some reason your share doesn't allow your account the WRITE_DAC
permission. This is no problem for native Win32 tools, because they
usually don't set file permissions.

There are two solutions to this problem:

- Check the permissions on the share, not only the ACL you see with
  cacls, but also the share permissions.

- Set the Cygwin mount point to the share to "noacl".


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


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