Message-ID: <4939FAEC.4050908@qualcomm.com>
Date: Fri, 05 Dec 2008 20:09:16 -0800
From: Rob Walker <rwalker AT qualcomm DOT com>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: CYGWIN=ntsec, "cp -a", and NT acls
References: <4939CF79 DOT 5010405 AT qualcomm DOT com> <4939DED2 DOT EB875495 AT dessent DOT net>
In-Reply-To: <4939DED2.EB875495@dessent.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Brian Dessent wrote:
> Rob Walker wrote:
>
>   
>> # make it read-only the windows way
>> attrib +R ${FILE}
>>     
>
> Note that the +R attribute (and attributes in general) has nothing to do
> with ACLs or security, it's a completely different concept.  FAT for
> instance supports R/H/S/A attributes but otherwise has a total lack of
> any form of ACLs.
>
> I think introducing the 'R' attribute really muddies this example,
> because Cygwin sort-of honors it as if it reflected the contents of the
> ACL, when it is a separate bit entirely.  You can see this in your
> example by adding some calls to getfacl.  You'll see that attrib +R
> didn't change any of the ACLs, but nevertheless Cygwin still reports it
> without the +w bit in the ls output as 0555 mode, even though its ACL
> still indicates write permission.
>
>   
>> The output of the examination above shows me that "cp -a" doesn't
>> preserve Full Control for the owner on the copied file.  Is this the
>> expected behavior under ntsec?  If I use CYGWIN=nontsec, Full Control is
>> preserved.
>>     
>
> Well cp is a POSIX program and it has no idea what Windows style NT ACLs
> are.  It preserves the Unix modes of the file, in other words it sees
> 0555 on the source file and 0555 on the destination file, so it's done
> it's job as far as it's concerned.  The problem of course is that there
> is not a one to one mapping of Unix modes to NT ACLs, so there is more
> than one way to express mode 0555.
>
> With 'nontsec', Cygwin doesn't even bother setting any ACLs, so things
> fall back to the default Windows way where the ACL is inherited from the
> directory, which is the same way that things worked when you used a
> Windows program to create the first copy of the file.  So the two files
> have identical ACLs not because of anything cp -a did or didn't do, but
> because they were essentially both created in the same manner and both
> inherited the default ACL of the containing directory.
>
> Also, another thing to note is that Cygwin uses the backup privilege of
> Administrator accounts to enable root-like unix semantics.  On a nix
> system if you are root you can do anything, regardless of permissions. 
> This is not so on Windows.  If you've got a file with mode 555, meaning
> there are no +w bits, then normal Windows tools won't be able to write
> to it which is why you are getting the error.
>
>   
>> Note the "Access is denied".  This is the issue I'm having.  I need for
>> the Windows programs to view the file copy the same way they'd view the
>> original file.
>>     
>
> To summarize, it seems to me that this is the situation: the source file
> has an ACL that indicates writable permission but has the +R attribute
> set, which Cygwin reflects as a mode of 0555.  You tell cp to copy the
> file and its mode, so it creates a new file and gives it mode 0555 as
> well.  This means it creates an ACL that denies write permission,
> because hey, user asked for 0555.  Since this is presumably an
> administrator account, you can continue to write to the file using
> Cygwin tools on account of its emulation of root, but you can't with
> native tools because the ACL doesn't allow it.
>
>   
>> This is obviously a contrived example.  I don't need to use "cmd /c
>> copy" and "cp" interchangeably, but there are a bunch of native Windows
>> tools that have the same behavior as "cmd /c copy".  Cygwin's
>> interoperability with these are my problem.
>>     
>
> So I guess my question is where is this wacky "set +R attribute" step
> coming from? 

[RGW] I'm simulating the case I actually have.  Our version control tool 
creates files that look this way (Owner Full Control, Read-only 
attribute set).


>  Or alternatively, why are you surprised that you ask to
> create an unwritable file and get something that's not writable?
>   

[RGW] I'm surprised that "cp -a" is unable to preserve the Windows 
attributes of the source file, which can be overwritten by Windows tools.

> If you want something that actually copies ACLs, not just replicating
> modes, then I guess you want to use getfacl/setfacl, e.g.
>
> $ setfacl -f <(getfacl "${FILE}") "${FILE}_copy"
>   

[RGW] Hm, looks simple...  Why isn't this part of "cp -a" ?

-Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/