Mail Archives: cygwin/2011/10/21/12:32:52
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
- Raw text -