X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Fri, 13 May 2011 16:41:05 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: CMD.EXE able to create files in directories on a shared drive, but bash in cygwin is unable to Message-ID: <20110513144105.GR3020@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20110513154205 DOT 91734baccmw9fygd AT messagerie DOT si DOT c-s DOT fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110513154205.91734baccmw9fygd@messagerie.si.c-s.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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 > (OI)(CI)R > (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