X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:content-type:content-transfer-encoding; q=dns; s=default; b=O0Z
	vrs+zDZW2jWyRFZrVx7jKdm+mjDsTLg2ATViRc4hmr4iHkpK2bL8Dy8Rc3BM98xX
	Y8yjI8CPqFfFyttBipNvgF7dVAxHUm6uDWAREcs6UxGYE0XJCxS6BS++96L6y9zm
	eKEC0LZoaH1tyEtkGwrt82miZpoVGh27DDtrUwZg=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:content-type:content-transfer-encoding; s=default; bh=jUZ49F6ON
	h2CRI6FObHCJsY3vXE=; b=Wn7spWhhZF/HynY50raq99eBDBaNssQH1s+BpBq2/
	zcNwtLaGxosx2ktdQNOIp5nS+W7IpGuODEQyKIHLDjI5Jk4xofWvUtNdPAprX1z5
	/zpRsv/5aCa+SKdUvsGZdQ7Ghqu90ywPfPlGCzLU0O8hHBAw4O1n3RK51rSGOJgV
	P4=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=1.9 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,FROM_LOCAL_NOVOWEL,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	mail-pa0-f65.google.com
X-Received:	by 10.68.90.132 with SMTP id bw4mr11156712pbb.102.1429336700202; Fri, 17 Apr 2015 22:58:20 -0700 (PDT)
Message-ID:	<5531F272.4070803@gmail.com>
Date:	Fri, 17 Apr 2015 22:58:10 -0700
From:	random user <cnpxzsdwle4m0dkt AT gmail DOT com>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
X-IsSubscribed:	yes

Hi again, Corinna.

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.

But I've noticed a few possibly-concerning items:

Item 1:

>> - I introduced a change in chmod behaviour which is not exactly in
     line with POSIX 1003.1e draft 17:

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.

A simplistic example use case:

# Create scripts for some app, with group set to give httpd or some
# other application login user read and execute privs. For sake of
# brevity, here only showing one directory, but reality would likely
# be a tree of dirs and files.  At least to my sensibilities, having
# the primary group be httpd here makes sense in what I'd like to see
# in 'ls', and what I'd like 'find' to be able to find most easily,
# even tho httpd is intended to have fewer privileges than the
# developers group will be given at times on these dirs/files.

mkdir appdir
chgrp httpd appdir
chmod 750 appdir

ls -ald appdir
getfacl appdir

#  Give developers write access.

setfacl -m "g:developers:rwx" appdir

ls -ald appdir
getfacl appdir

# Production use period, try to prevent changes.

chmod ugo-w appdir

ls -ald appdir
getfacl appdir

# Development period: Reenable changes by local-machine developers -
# but did NOT intend to enable writes from the http daemon which may
# be up running other applications.  On Linux, remains 'group::r-x',
# only mask gets changed.

chmod g+w appdir

ls -ald appdir
getfacl appdir

---

Item 2:

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.

Cygwin mkdir seems to create some to-be-inherited ACLs, even if the
parent directory has had 'setfacl -k' applied (and so it's clear these
aren't being inherited down, they seem newly added by mkdir or some
library call it makes):
  CREATOR OWNER:(OI)(CI)(IO)(F)
  CREATOR GROUP:(OI)(CI)(IO)(RX,W,DC)
  Everyone:(OI)(CI)(IO)(RX,W,DC)
(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.

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?), 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.  So even with umask = 0, I now get only
0700 on newly created files in a directory that itself has 0700,
rather than 0777 as I get on older Cygwin and on Linux.  (What I
actually get seems to vary based on the directory-creation-time umask,
or whatever ACLs the parent directory itself inherited via this
mechanism, as noted in prior paragraph's parenthetical.)

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.  (I had in past remembered stuff
like "CURRENT SESSION", but doing a test now using 'echo x > file'
under cmd I find I get <my user>(F), cyg_server(F), Administrators(F),
and SYSTEM(F) tho none of cyg_server, Administrators, nor SYSTEM are
present at all in the ACLs of the parent directory, and <my user>
isn't cyg_server.)  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.

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"?

I note that chmod doesn't keep these to-be-inherited entries in sync
with the directory's mode; they seem stuck at their create-time values
unless changed explicitly with icacls.  (And am I right that these
can't be easily changed with setfacl, since the SIDs involved don't
have Cygwin user/group mappings?)  This seems true of both this test
drop and older Cygwin.  Intuitively this feels not-quite-right, but
seems a separable concern from the above and isn't a current change.

---

Item 3:

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.  This is also seeming to be interacting with the "Item 1" topic,
leading to surprising grants to the file's primary group (when that's
*not* the same SID as the owning user).

umask 77
mkdir testdir

ls -al testdir
getfacl testdir
icacls testdir

setfacl -m "u:${USER}:rwx" testdir

ls -al testdir
getfacl testdir
icacls testdir

chmod u-w testdir

ls -al testdir
getfacl testdir
icacls testdir

---

Item 4:

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?


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -