Re: CYGWIN=ntsec, "cp -a", and NT acls

[Brian Dessent <brian at dessent dot net>]

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?  Or alternatively, why are you surprised that you ask to
create an unwritable file and get something that's not writable?

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"

Brian

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