DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=cZlCwsFPSq8pS/yG2iPsGnWuRlzGQ2OUpCG1iUU/UPxbcoOUUsvmj
	mXhawdUUXegcq1WJ2NMz8pxT2zrn2Wbjm+gnT8s0Qi1mWBfJ6UsMh1JJLG6hX6mF
	w/ouE72bbCxb7QZA/ANALLrD6a4/GDUlCgozw4L+l+ZOizq08ObXuY=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Thu, 13 Aug 2015 18:33:02 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Shares with strange ACL settings
Message-ID: <20150813163302.GB28349@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <loom.20150811T101658-176@post.gmane.org> <20150812152601.GL13029@calimero.vinschen.de> <loom.20150812T172703-7@post.gmane.org> <20150812155817.GN13029@calimero.vinschen.de> <878u9g9y6b.fsf@Rainer.invalid> <20150812183220.GO13029@calimero.vinschen.de> <87vbck8h92.fsf@Rainer.invalid>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <87vbck8h92.fsf@Rainer.invalid>
User-Agent: Mutt/1.5.23 (2014-03-12)
Note-from-DJ: This may be spam

--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 12 20:59, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> I think so, but there are likely some corner cases.  But I think that
> >> had been proposed and shot down already, so I was trying to come up wi=
th
> >> something less intrusive.
> >
> > This is relatively unintrusive.  The current user token is always
> > available.  So if owner =3D=3D current user, for every group in the fil=
e's
> > ACL just check if it's in the current user token and, if so, add the
> > perms of that group to the owner perms.
> >
> > Sounds pretty neat as an intermediate solution to me.
>=20
> I'd play the guinea pig for that snapshot=E2=80=A6 :-)

This puzzles me a bit.  As example you gave something like

  ----rwx---+ gratz Domain Users [...] foo

Given the code in recent Cygwin versions, this shouldn't happen if the
user gratz is member of the Domain Users group.  The current code
doesn't test all groups in the ACL, only the primary group, but that's
sufficient in most cases.

So this could only happen if you modify the permissions of windows files
using Cygwin tools and Cygwin helpfully gernerates a DENY ACE for the
owner.

I'm just not exactly sure about the way to go to get these permissions
in a non-artificial scenario.  But I can reproduce it like this:

- The file xxx has a primary group different from the group which has
  permissions, e.g.:

    owner:  foo
    pgroup: foo_group

    acl: 1 entry
      bar_group: full control

- ls -l xxx
  ----rwx---+ 1 foo foo_group 68565 Aug 10 10:37 xxx

- $ chmod g-w xxx

- Afterwards, the POSIX-like ACL looks like this:
  $ icacls xxx
  xxx foo:(DENY)(S,RD,REA,X)
      foo:(D,Rc,WDAC,WO,RA,WA)
      foo_group:(RX)
      Everyone:(Rc,S,RA)
      bar_group:(RX)

So, what's going on here and how do we really fix it?  It *might* be
prudent to drop any efforts to create DENY ACEs to reflect the POSIX
perms.  That results in the documented permission gap between POSIX and
Windows permissions, though.  There's just no way to express all possible
POSIX permissions using Windows ALLOW ACEs only.


Corinna

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

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVzMa+AAoJEPU2Bp2uRE+gZ/EP/RJi1uqB659/hqMt6FDn7duE
j4szjqYQDwn02m7M9gEiiIzckG8XT+03FhHUQLVaoAEttXAV0HV/aoLzK9hX9NF/
u7V6y5XxNyorTKmDVolnzJh6BwdO2KARFUDU81Rk5hIgxbLvdHL7zub4PApeQ9xO
QTLrLnINWuRM+Cqi3obuDyC0q40LhxIadjAJDo+lMMvL+RYDp8rARP7MzyPloAOU
X2GEYUVq0FOVpf211zSwsFY03C15X1YtzHP53Kr7HmGZGv5nG7oV1lu5G65+zP+F
7EOAuWLcupXAJCkif4kWQtDD/G/k/uWIxVSif0caJda+T23lG9O2s85NQ0H5hIRB
+27Q57vKIeml920y3768aQxu9ARHWL8LqO+G3x9PrtapHvO9ArIYVenpMXDcfOO+
43DFbcCze7ZMxruWpTk6WyzQFvT8IJCs54jKwXZBQmgRWlFS7aBuVxHq+HCT7VlP
XTaWmg3BrkDLzj+DHEo9AvpzwAVEec2cf6xTnx16sArM5VNnpxvMvQp4UbA1yoDM
LxuicPGOP73HHdlWQoGi+nWVA+Ru4Ue2UhL12Q8LPxZnQ+t0n/4DdPg5YG7fCo9/
TYF7IjmXKCyuypxnPCR1ZRHlMCORkAp6S1QKdpGx+PYk+WJoTYMch0hniRyDuNyo
s6bQpr6zqbVLtUIef9Ki
=iQ1o
-----END PGP SIGNATURE-----

--W/nzBZO5zC0uMSeA--