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=lI+iqd7hiAFRqQYBVgTF+scVfdng33P8/gDrzri5B9WLx8h9lZ2+m
	panQUPTkIO4uQ5LrLUcuMXR6j7Pss7cjUn/6F7cDEU7OqV0m29Eq5SCc/NkysqaD
	GBn0ssOURL/KGVNInEIywxBqo4sPEuukGzh4hX0qRRhRzx0BzKL2+Q=
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
Date: Sun, 1 Mar 2015 10:27:44 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Too Many Permissions Stripped In 1.7.35?
Message-ID: <20150301092744.GG11124@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <54F00036 DOT 8050509 AT gmail DOT com> <54F233D8 DOT 1040503 AT gmail DOT com> <54F26595 DOT 3030400 AT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="7U7nS7UhGMyosb9W"
Content-Disposition: inline
In-Reply-To: <54F26595.3030400@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Note-from-DJ: This may be spam

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

On Feb 28 17:04, random user wrote:
> Re the user SID !=3D group SID, chmod -x case: Thanks, sorry to have
> wasted your time. It does seem the same on Linux, and chmod ug-x does
> appear to work correctly. My bad.
>=20
> Re the user SID =3D group SID case:
>=20
> I'm not offhand spotting how to use chmod to create the ACL your "They
> do:" example displays.

It hasn't been created with Cygwin.  I created it for the sake of
explaining how Cygwin evaluates an ACL to emulate POSIX permissions.

> With 1.7.35(0.286/5/3) 2015-02-27 17:16,
> Everyone permissions don't seem to leak into the group mode for the
> file owner user SID !=3D group SID case. After a "chmod 607 x" where
> file owner user SID !=3D group SID, I see in ls
>   -rw----rwx 1 XXX YYY 0 Feb 28 16:28 x

  $ chmod 607 xxx
  $ ls -l xxx
  -rw----rwx 1 corinna vinschen 0 Feb 28 23:04 xxx
  $ icacls xxx
  xxx VINSCHEN\corinna:(DENY)(S,X)
      VINSCHEN\corinna:(R,W,D,WDAC,WO)
      VINSCHEN\vinschen:(DENY)(W,RD,REA,X)
      VINSCHEN\vinschen:(Rc,S,RA)
      Everyone:(RX,W)

Does that explain it sufficently?

> For the user SID =3D group SID case, further testing seems to show that
> what gets presented now as the group mode is actually the bitand of
> the user and Everyone permissions. Is that correct?

No.  *At creation time of the ACL* the user bits are or'ed with
the group bits to constitute the user bits.  The *created* group bits
are 0:

  $ chmod 421 xxx
  $ ls -l xxx
  -rw------x 1 corinna corinna 0 Feb 28 23:04 xxx
  $ icacls xxx
  xxx VINSCHEN\corinna:(DENY)(S,X)
      VINSCHEN\corinna:(R,W,D,WDAC,WO)
      Everyone:(Rc,S,X,RA)

whereas in the user !=3D group case:

  $ chmod 421 xxx
  $ ls -l xxx
  -r---w---x 1 corinna vinschen 0 Feb 28 23:04 xxx
  $ icacls xxx
  xxx VINSCHEN\corinna:(DENY)(S,WD,AD,WEA,X)
      VINSCHEN\vinschen:(DENY)(S,X)
      VINSCHEN\corinna:(R,D,WDAC,WO,WA)
      VINSCHEN\vinschen:(W,Rc,RA)
      Everyone:(Rc,S,X,RA)

>=20
> (I had interpreted from the announcement email that group mode bits
> would show as =3D Everyone mode bits.)

I'm under the impression you're confusing things.  There are two
kinds of ACLs, the ones that have been created by Cygwin who's
trying to emulate POSIX permissions by creating the right kind
of deny and allow ACEs, and then there are ACLs of unknown source.
Even in case of the latter, Cygwin tries to translate them to POSIX
permission bits.  If you have a Windows ACL like this:

  user:      rw-
  group:     r--
  everyone:  --x

the resulting POSIX permissions are:

  user:      rwx
  group:     r-x
  other:     --x

Because Everyone is not the same as "other".  Permissions given to
everyone have to be mirrored into the permissions of user and group.

> >From an actual security point-of-view, seems either representation is
> reasonably accurate, as all the actual privileges granted are always
> shown in the user permission mode and there can't possibly be any
> "members of the group" other than the user for the group SID =3D user
> SID case. Is that thinking correct?

Yes.

> But the current approach seems to lead to inconsistencies at the
> appearance level. Everyone bits don't appear to fold into the group
> mode at all if user SID !=3D group SID, as seen above.

Again, cygwin ACL !=3D "some other" ACL.  The Cygwin ACL comes with
matching deny ACEs.

> There also seems an inconsistency introduced between the apparent
> group mode as it shows in ls and the group mask. Am I right in
> thinking that in Posix these are meant to be the same?
>=20
> rm x
> umask 077
> touch x
> chgrp <same as user SID> x
> setfacl -m 'g:SYSTEM:r--' x
> ls -al x
> getfacl x
> chmod o+w x
> ls -al x
> getfacl x

Yes, there's an inconsistency and I'm not going to change it for now.

As I wrote in other mail, the code in question is split into two sets of
functions for historical reasons.  The stat/chmod/chown functionality is
one set, the acl(2) call is the other set.  I was trying to improve
acl(2) lately, but the underlying problem, two sets of functions with a
slightly different idea how things are suppsoed to be is getting in the
way.  That's why I'm going to rewrite this stuff later this year.


Corinna

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

--7U7nS7UhGMyosb9W
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJU8tuQAAoJEPU2Bp2uRE+gIngP/0h4lpNhGJZR1QUQTZ7IwqhD
xLNL9RCL/fHrGoUMyPBFs4rdkTVKtDu6zjJMc+nq71FOZj0ucn54nHwrRmR0j0Wv
sUR+lovxMCsKYQSzll3kgpF70kkq9pxIPPjIUoQo5v5H9QAOeINs4YtAIvS8BwZl
LsxdNQNkESugIWHOeauTNC9gKopQ5V162y9qRCXSCfQpVO0szB/kiwL+izV56g2Q
0vOVCYH36749bfaNh266R23Xfefqw6VXwNQMwFHbTcypBY3xYIOgvf1BHiAqPu0j
9/EeanWqAFPUuGf09N3H8G0CqunRWMh8dYTaFRmS5FFSoAo+I0F0w7qbcHVh32fG
WAHHWO96z0UuYW2vuPSfFJNWiq8ZjulUvCXijzU+NPpA0xLZFrs2VSCGaTr5ThZT
7m06KLT/w0N4pXL0JLXjAPCIKRg4p/R72p66qUltG3HpsEAbzprE366kvNixjTfe
NZj/LsYdO/GWLnQsNpqCiyQFeodvOXFSKv8MlEs3Z24CxoT9gNnXB+VG7wd+FPvW
W9usqLAH1dM/7waqJGPvZ2379ybqcKBZEBTH/Gy3Itk9+du2iMsBj88q5xEpx81/
mUNzJfefGDhT5I6doKIZMrg5zfEdbo2szJdY60dR559W720sLj7RxyAJSJ62I8Ji
2GTtt/8jF7jVPUFb6A+L
=920R
-----END PGP SIGNATURE-----

--7U7nS7UhGMyosb9W--