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=lkA8+GibH/CxXXjsj3Ka8z03vfg85TBN4ncStBp/ZqGfO2mBFhwt3
	xpBE7h0MahFOEMbz2m6swpTLi0/uvaHVK2kgYQSBZt5Ar1reW+pDzVA08UkSbfQe
	If2VkpNSjk0uRno2pjjj9FMD2fzjdgulxgydeBp26MhwAVJcUBy1oU=
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: Sat, 18 Apr 2015 12:06:12 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
Message-ID: <20150418100612.GK3657@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <5531F272 DOT 4070803 AT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="Edk6HoYKP7RsK9ib"
Content-Disposition: inline
In-Reply-To: <5531F272.4070803@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

Hi random user (at least a first name would be nice, you know my first name
as well, isn't it?),

On Apr 17 22:58, random user wrote:
> Hi again, Corinna.
>=20
> I appreciate these recent changes, the more complete Posix ACL support
> looks beneficial for sharing/syncing files between Cygwin and Linux
> machines, and for more compatible scripting.
>=20
> But I've noticed a few possibly-concerning items:
>=20
> Item 1:
>=20
> >> - I introduced a change in chmod behaviour which is not exactly in
>      line with POSIX 1003.1e draft 17:
>=20
> This change looks to me to be somewhat dangerous.  I'm concerned it
> may lead to granting privileges one doesn't expect to have granted.
> And scripts leveraging this would behave noticeably differently on
> Cygwin than they do on Linux, leading to extra time to debug/recode.
>=20
> A simplistic example use case:

Ok, I understand the concern here, but I really didn't do that change
out of the blue.  Maybe I'm just dumb, but I puzzled myself with this
behaviour a couple of times.  I think that this specific behaviour
defined in draft 17 is surprising for the end user.

The difference between Linux and Cygwin is that Cygwin users have *lots*
of ACLs with default permissions for secondary users by default while
on Linux this feature is used in limited circumstances.  So without this
change, what Cygwin users get is something like this by default:

  $ touch foo
  $ chmod g+w foo

  [switch to another user, member in the same group]

  $ echo bar >> foo
  echo: Permission denied

A Linux user will never encounter this behaviour in the default case.
This is what concerns me a lot and what triggered this change.

I'm willing to rethink this change, but for the time being I'd like to
keep it this way and test it with a bigger user base (not only the few
testers).

> Item 2:
>=20
> I'm having troubles figuring out how to create a directory that plays
> well both for providing old-style umask behavior and as a holder of
> files created by non-Cygwin Windows apps.

Yeah, I know what you mean.  Here's another example of following 1003.1e
to the letter while at the same time trying to accommodate native
Windows applications...

> (The actual permissions in these seem to vary based on the umask
> setting and any inherited ACLs at time of directory creation.)
> This seems existing behavior in Cygwin, still present in this
> test drop.

(This is very old code.  Windows applications rely on inherited ACLs, so
creating Cygwin folders POSIX style, without inhertable ACEs, will
result in weird permission settings for files created with native tools)

> What I seem to be seeing is that with these present, this test drop
> appears to now be treating the directory as having "extended ACLs" (is
> that the proper phrasing?),

(default ACL entries in POSIX speak, inheritable ACEs in Windows)

> and so now will use these default: ACL
> entries to create the permissions for a newly-created-by-Cygwin-app
> file rather than using umask.

...the 1003.1e part being to apply the umask only if the file does not
come with inherited permissions.  Due to the default ACEs created by
default, all files will have inherited permissions and thus umask is
seldomly applied.

Yes, that's a problem.  The underlying problem is that you can't
distinguish inheritable ACEs created by Cygwin just for the sake of
Windows applications from inheritable ACEs created explicitely and
willingly to have the same behaviour for Cygwin apps.  They are
identical to the bit.

So it's not clear in this scenario when to apply umask.  From the
1003.1e perspective the code is doing the right thing, but the result
may, again, be surprising.

Any suggestions?  Always applying umask, no matter what?

> I can use 'setfacl -k .' to remove these, but then if I try to write a
> file into the directory using a non-Cygwin program I end up with a
> rather strange set of ACLs on it.

Typically you get the default DACL from your user token:

  $USER  rwx
  SYSTEM rwx
  Admins rwx

> I suspect the desire to allow non-Cygwin apps to
> sanely create files in a Cygwin-created directory is likely the reason
> that mkdir is creating these ACL entries.

As outlined above.

> Would it maybe make sense for 'setfacl -k' to keep/recreate the same
> base set of to-be-inherited ACLs that mkdir does, and for the
> determination of whether to use umask vs. the default: ACLs to ignore
> these?  Maybe for better cosmetics, for getfacl to not show these, nor
> ls to show these cases only as causing a '+' to appear, so that a
> newly-created directory with no ACLs inherited from above would appear
> both visually and behaviorally as not using "extended ACLs"?

No.  I really don't think so.  Again, the point is that you can't
inherited ACEs for Windows-only from explicit default ACL entries
created by a user.  Second guessing here and not showing entries
will even be more surprising.

> I note that chmod doesn't keep these to-be-inherited entries in sync
> with the directory's mode;

Yep.  Did you check against Linux behaviour?

> they seem stuck at their create-time values
> unless changed explicitly with icacls.

Why icacls?  Just use setfacl.

> (And am I right that these
> can't be easily changed with setfacl, since the SIDs involved don't
> have Cygwin user/group mappings?)

Hmm, that sounds like you never actually tried it...

> Item 3:
>=20
> It seems to create rather messy/redundant ACLs if one tries to use
> setfacl to adjust the owning user's privileges explicitly by user
> name.

As on Linux:

  $ touch foo
  $ getfacl foo
  # file: foo
  # owner: corinna
  # group: vinschen
  user::rw-
  group::---
  other::---

  $ setfacl -m u:corinna:r-- foo
  $ getfacl foo
  # file: foo
  # owner: corinna
  # group: vinschen
  user::rw-
  user:corinna:r--
  group::---
  mask::r--
  other::---

I found that a chmod u-w then results in permission denied messages when
tring to change the permissions back, though.  That's clearly a bug.

> Item 4:
>=20
> Just a question (tho if 'no', then a 'wish list' vote for some
> "soonish" future release): Is this coming release likely to provide
> the right APIs for ACL handling that we can then build tar enabled to
> save/restore ACLs?

I don't understand the question.  Cygwin provides the low level ACL API
from original Solaris.  Keep in mind that the orignal code in Cygwin is
older than the Linux implementation.

Do you mean the POSIX API?  If so, I'd be glad if somebody would take a
stab at implementing the POSIX API in terms of the underlying Solaris
API.  Really, *really* glad.


Corinna

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

--Edk6HoYKP7RsK9ib
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJVMiyUAAoJEPU2Bp2uRE+gxLQP/idGWX/zCBIAVnsx8RoW2jA6
bxRrSWHexQutNKLw6d7UnWTm2+gJ65Lsb1uNtPPmrEZ9ufJqkfzNz8AyiXDaJ62k
kURvBARVsvIRPqynHAsXWnIazgykDzywYH9HuqbLLogyllb1GtYT00SiwybBpOTt
IxAu/gIbwO2WaOaxzU+e4bHGXqMxwLjkA6UyNW+4az7mOh+EyjbQU/xYdo7Yhh4T
ySlgZiWd/viHMqi4BHydh9/eU4FEs/9LGhlWyKbcb1paY/+SXSH8HHp6njUvmXYy
lPa9ZJd4NJ/UqK3cNRjUmyAAV8Yw0xozy/CkYN5IvdwICbDTy8xvHTEbawvgWtc/
W8Whxo/AMSw8DYom3Y6H0D7XzQ+/a6EQSfpuDk2CQChn7MYEYrlEjMHtiMVts5nN
CKwBXniom9fkbMkvIPWuA/htHRwTNj1VZ/ILCiXFQSWHpOmL7a7djpvnyGMOunI3
BqVEQM+KJuHSgKaFvXpgw4U43uq0mcH3ivzp51N3IvozzzQtKKHK3R5FDe1G0vlQ
8y8ojmN96RCVe74DzTe/oF6HhqccqrqOclGLKZX1IitGlsgJQokBD8ZQdkXIXAMP
fQwPPo8QN/H0buIfvQtLu74ExPfARJVxl70WbcLt/2U4XrwYREi+83Nx1eUQk5BJ
k838hddgFTe6PxZMw4zV
=WdEt
-----END PGP SIGNATURE-----

--Edk6HoYKP7RsK9ib--