Mail Archives: cygwin/2008/12/05/23:10:38
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/
- Raw text -