On Apr 22 20:35, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Hmm.  Can you try the same with the latest developer snapshot I just
> > created?  I found this problem which created undesired DENY ACEs,
> > maybe this was the reason /knock on wood/.
> 
> I ran out of time, but I've managed to install the snapshot and did a
> quick test before going home.  The ACL looks saner than before and I can
> regain access via chmod, so that's good.  The basic problem however
> remains and I'm really not sure if that's a bug in rsync or in Cygwin or
> even a bug at all.
> 
> The file to be copied has, as stated before, access granted only via a
> share group (actually three of them, but that's not a factor).  So
> CREATOR OWNER, CREATOR group, the original owner of the file and myself
> (owner of the newly created file) have no DACL entry on the original
> file and the resulting file mode is "---rwx---+".  For "rsync -av" this
> means that after the copy the mode is set to 0060 and that explicitly
> locks out (via DENY) CREATOR OWNER CREATOR GROUP and myself.  That gives
> the same POSIX modes, but not the same access rights of course.  For
> "rsync -av --acls" the same happens and then some ACL are copied over
> from the original file, which still doesn't get me access since the
> DENY ACL is first in the list.
> 
> This might be a hole in the ACL mapping to POSIX file modes.  The way I
> see it the reported file mode should actually be "rwxrwx---+" for the
> original file since that's the effective access granted by Windows and
> there are no POSIX flags on the original file (via NULL SID).  Just like
> on POSIX (where it's done via mask) the user flags can only be cleared
> in this situation by an explicit chmod (which then gets implemented via
> DENY ACL I suppose).

You may be right here.  The problem is that we have two kinds of ACLs
to handle, the ones created by Windows means, and the ones created
by recent or older Cygwin versions.  It's rather bad that we can't
distinguish them.

But then, how do you check an arbitrary ACL for the effective rights
it creates for all affected parties?  I may be missing some API function.
but I don't see a Windows function generating some kind of effective
ACL.  There's only the function AccessCheck() which gets a token and an
ACL as input and then tells you the effective rights of the user with
this token.  This gets very slow and complicated, very quickly.

I hate to admit defeat, but it also seems that the method I used to
handle real vs. effective rights just doesn't work as desired.  In
theory we don't want the DENY ACEs having any effect before visiting the
ALLOW ACEs.

Ideally the DENY ACEs should only point out what the real access rights
are, and they should secure the access against the next group, along
the lines of

  NULL     DENY
  user1    ALLOW	# Only effective rights
  user2    ALLOW	# ...
  user1    DENY		# Point out real permissions, somehow
                          Secure against excess group permissions
  user2    DENY		# ...
  group1   ALLOW	# As above
  group2   ALLOW	# ...
  group1   DENY		# As above, secure against excess Everyone perms
  group2   DENY		# ...
  other    ALLOW

This needs yet another rewrite, but this will take a lot longer than
this first cut.  I guess we should create a new Cygwin release without
this new ACL handling change for now to get the bugfixes out.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat