X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.3 required=5.0	tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: gds <gds AT chartertn DOT net>
Subject: Re: cygwin permissions problem on a network drive
Date: Fri, 21 Oct 2011 12:32:01 -0400
Lines: 165
Message-ID: <j7s6q4$b0d$1@dough.gmane.org>
References: <CC0D9E8456BA41488A76AFE4E8F3A36902731CC0 AT de011305 DOT de DOT ina DOT com> <j7q925$5sd$1 AT dough DOT gmane DOT org> <20111021085010 DOT GF13505 AT calimero DOT vinschen DOT de> <CC0D9E8456BA41488A76AFE4E8F3A3690278A577 AT de011305 DOT de DOT ina DOT com> <20111021105510 DOT GC2979 AT calimero DOT vinschen DOT de> <j7rus9$e59$1 AT dough DOT gmane DOT org> <20111021143913 DOT GE2976 AT calimero DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110906 Fedora/3.1.14-1.fc14 Thunderbird/3.1.14
In-Reply-To: <20111021143913.GE2976@calimero.vinschen.de>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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 10/21/2011 10:39 AM, Corinna Vinschen wrote:
> On Oct 21 10:16, gds wrote:
>> On 10/21/2011 06:55 AM, Corinna Vinschen wrote:
>>> On Oct 21 12:15, Lemke, Michael  SZ/HZA-ZSW wrote:
>>>> On Friday, October 21, 2011 10:50 AM
>>>> Corinna Vinschen wrote:
>>>>>
>>>>> On Oct 20 18:58, gds wrote:
>>>>>> On 10/18/2011 08:52 AM, Lemke, Michael SZ/HZA-ZSW wrote:
>>>>>>
>>>>>>>
>>>>>>> I know this an old thread but I am in exactly the same situation as
>>>>>>> the OP.  Access with 1.7.7 and before worked fine, 1.7.9 has this
>>>>>>> problem.  The workaround with explicit noacl option works for me but
>>>>>>> it is rather awkward as I have to work with a lot of servers.
>>>>>>>
>>>>>>> So...
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>> ...has this happened now?  In a snapshot?  I couldn't find any
>>>>>>> further information.
>>>>
>>>> So from the reply below I take it hasn't been fixed/worked
>>>> around in a snapshot.  But my experiments show something has
>>>
>>> Wrong.  It has been fixed in the snapshot.  1.7.9 tries to open the file
>>> with WRITE_DAC access which fails on some shares.  The snapshots won't
>>> do that anymore.
>>>
>>>>> I explained what the problem is already.  The buzzword is WRITE_DAC.
>>>>> Apparently you don't have permissions to change file permissions
>>>>> on that share.  Cacls should show the exact layout of the file and
>>>>> directory DACLs.  Does `chmod' work for you?  It shouldn't either.
>>>>
>>>> In my case that it true, chmod fails.
>>
>> For me chmod *appears* to work (no errors on cmd line) but file
>> permissions seen in "ls -l" don't change nor do they change in
>> windows.
>
> This is *with* using the "noacl" mount option, isn't it?  Without
> the "noacl" option you should get a "Permission denied" on chmod.

Actually, I thought I was in normal mount mode with acl enabled but not sure. So 
tried experiment again...

Right now, my mount shows this for o: drive:
O: on /my-o-drive type ntfs (binary,noacl)

I can cd to /my-o-drive/home/gds and do:
rm testfile
echo 1 > testfile
cat testfile
1
rm -rf testdir
mkdir testdir

and all work.

If I do chmod 000 testfile I see with ls -l:
-r--r--r--
If I do chmod 777 testfile I see
-rw-r--r--
So there is a small effect but not much.

Now I change the mount so I see (the default):
O: on /cygdrive/o type ntfs (binary,posix=0,user,nounmount,auto)

and repeat the exercise (testfile and testdir previously deleted:

cd /cygdrive/o/home/gds
echo 1 > testfile
bash: testfile: Permission denied
mkdir testdir
mkdir: cannot create directory `testdir': Permission denied

This is with the current default cygwin1.dll, not a snapshot.

So apparently, only with the noacl style mount can I create files or dirs via 
cygwin. And definitely if app using cygwin tries to change a permission, 
currently noacl is required.

Apparently Michael Lemke is saying with a SS dll you can at least create 
files/dir via cygwin (that I may have also seen when I tried a SS dll, not 
sure). However, for me, I have to now use the the noacl mount method since my 
application (svn) needs to create files and dirs on the share and it also tries 
to set permissions.

Sorry, in reading your previous explanations (quoted below), I am still not sure 
whether you are saying this new behavior is a feature or bug in cygwin, a bug in 
my app using cygwin (e.g., svn) something changed in windows setup of 
permissions. Just to put it here (since thread has become separated) here is 
what you said previously:

<begin quote, Corinna>
I know what change in Cygwin is causing that problem, but unfortunately
I could never reproduce the server share settings myself which result in
the permission denied.

<some snipped>

If you want to discuss this with your admin, the problem is this:  When
Cygwin 1.7.9 tries to create a file on a filesystem which supports ACLs,
it requests WRITE_DAC permissions in the open call.  WRITE_DAC is the
access right you need to create the permission bits in the file's ACL,
what you see in Explorer under the Security tab.

Now, in some environments, the settings of the shares are so, that this
right is apparently not granted, even for the creator of the file.
But, as far as earlier reports go, there seem to be no indication of
this in the ACL.  As I mentioned above, I experimented with this
myself, but I have never managed to reproduce this setting on the server.
So I neither know how this setting looks like, nor if there's a way
to recognize such a share.

So, for the time being, I will change this in Cygwin for the next
version so that it doesn't request WRITE_DAC permissions when trying
to create a file or directory on a network share.

The result will be that every file creation on a network share with ACL
support will try to open the file twice, the first time to create it,
the second time to set the POSIX permissions.  This slows down remote
file creation again, but I don't see a useful way around it.  Testing
for an access denied error afterwards and trying again is rather
awkward.
<end quote, Corinna>

Anyhow, with the workaround of using noacl mount, it is working OK for me. Let 
me know if there is anything more specific I can check. Thanks!

>
>> Also, in
>> windows, I can't change any of my access rights; under file
>> properties/security under "allow" all are checked except Full
>> Control and Special permissions, none checked under "Deny" and all
>> check marks are gray so I can't change them there either. Anyone can
>> create, modify or delete any file, but no one can hide or
>> write-protect any file (which would require changing
>> permission/access rights).
>>
>> AFAIK, this is how it has always been on this share. If this
>> assumption is correct, does that mean something changed in cygwin
>> that is causing this possible bug?
>
> I explained that in this thread.  WRITE_DAC vs. not WRITE_DAC.

Thanks, copied it above.

>
>>> Then "noacl' is the only way for you.
>>
>> Yes, no snapshot cygwin1.dll helped. Went back to default. Now have
>> only this in /etc/fstab:
>>
>> O: /my-o-drive	dontcare binary,noacl 0 0
>>
>> So now access drive with /my-o-drive instead of /cygdrive/o
>
> Yes, that's how it's supposed to be in your situation.
>
>
> Corinna
>



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