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
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=KwcJZ/gVU5dP40xQW0jReUtAGyN3cv10UFJrdb2b4dc
	E3nkQuzAdNPaNOM75B3iKYA/Jtoxe3Sw41ojht8i8MqD6L3szjDVsZ5PWKiLNlBF
	IpJuqIy/lM2RZWCJLnP5LQ93LJ2HLvcgTaJqe5XyC8kKEdVamrm3BqA9BrUpa9sM
	=
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
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=u0vc3wY4nAr9yeksR46Ven90KOI=; b=V1a3oREtRIFB5Ng1e
	2k4uI5WV2eqRBm/g9QdxJr84nWcVgDlf6DkWhGafKaCWpKaiwYRaowVMyWgpUB69
	m3iXtd52btM1OvBIsLrkaB06tkcVx8mGYOZR55OJ/0clC3QCd15R1j1SvZ2RPMI/
	mbEsfdcK/OAYKEuso4KcxDyr6U=
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=2.1 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=no version=3.3.2
X-HELO:	mail-pd0-f179.google.com
X-Received:	by 10.66.231.209 with SMTP id ti17mr32914358pac.80.1429583253250; Mon, 20 Apr 2015 19:27:33 -0700 (PDT)
Message-ID:	<5535B590.7020806@gmail.com>
Date:	Mon, 20 Apr 2015 19:27:28 -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:	Re: issues seen in TEST RELEASE: Cygwin 2.0.0-0.7
References:	<5531F272 DOT 4070803 AT gmail DOT com> <20150418100612 DOT GK3657 AT calimero DOT vinschen DOT de> <5534152B DOT 3050908 AT gmail DOT com> <20150420091802 DOT GN3657 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20150420091802.GN3657@calimero.vinschen.de>
X-IsSubscribed:	yes

Thanks for the explanation/correction about umask's non-impact if
there are default ACL entries.  I'm not recalling exactly what I had
seen on Linux that made me think there was an impact.

>> If the incoming, inherited ACL contains the three entries for user,
   group, and other, it's with very high probability inherited from a
   Cygwin created directory.  If the inherited ACL contains nothing
   else, we're going to apply umask, otherwise we don't.

Sounds like that'll maintain current behavior reasonably, thanks.

>> So what's the point?  On Linux the "default-default" entries are
   not changes with chmod, and on Cygwin they aren't either.  And
   that's the right thing to do on both systems.  A chmod on a dir
   never influences the mask of files created in that directory.

I wasn't trying to suggest chmod should change these.  It's mkdir I
was wondering about, wondering whether it should stop trying to mirror
the directory mode into the "default-defaults", just always set as
     CREATOR OWNER:(OI)(CI)(IO)(F)
     CREATOR GROUP:(OI)(CI)(IO)(Rc,S,RA)
     Everyone:(OI)(CI)(IO)(Rc,S,RA)

I change my mind on this tho, noticing that if on Linux I have a
directory that's mode 550 with no other ACL entries yet existing, and
do a "setfacl -m 'd:g:adm:rwx' .", the result also includes new
default ACL entries for d:u::r-x and d:g::r-x.  If mirroring the
directory's own mode is the way the Posix-behaved default ACL entries
are to be created, it would seem best that the Cygwin-mkdir-created
ones would continue same.

But I'm still thinking it'd be goodness if setfacl were to create the
same to-be-inherited entries as mkdir does if no other to-be-inherited
ACL entries end up present, so setfacl would never leave a directory
with no to-be-inherited ACL entries and so lead to troubles should a
non-Cygwin program create a file in it.

>> Sorry, but that sounds much too complicated for my taste.
>> I'm only concerned about the behaviour of the underlying functions
   in Cygwin for this, and it should be *simple* so that the logic
   isn't too confusing and still understood in a year.

What wasn't about the "default-default" entries was intended to see if
you might like a possible alternative idea for dealing with SYSTEM,
ADMINISTRATORS, and other administrative/Windows-program-purposed ACL
entries.

Goal is to no longer have these have impact on the visible mode bits,
to deal with the topic of prior complaints as you seem now trying to
do for SYSTEM and ADMINISTRATORS, but there do seem remaining desires
expressed in recent emails to have other SIDs able to be similarly
treated.  And now also to prevent these alone from triggering the new
"extended ACLs" behavior.

The thought is rather than special casing by SID, instead separate
(via your new use of DENYs, NULL SID entry, etc.) by whether a
particular ACL entry has been created/modified by new-version Cygwin
setfacl or not.  Entries that have/haven't should be able to coexist
in the same ACL, marked by presence/absence of a preceeding DENY.
Thus any SID could be used for a non-Posix-purpose/behavior ACL entry,
and on the flipside should someone desire they could create a
Posix-behavior ACL entry for ADMINISTRATORS.  For any ACL entry not
created/modified by new-version Cygwin setfacl, other than the ones
representing the simple mode permissions, Cygwin would simply choose
to 'say' "that's not a Posix-behaved one, I'll neither show it nor
change it."

What if at the Cygwin library/Posix-API level, the acl_*() functions
(or I guess their Solaris equivalents in current Cygwin coding) would
simply not include these at all?  And similarly the permission mode
bits would simply not include any impact from these, chmod would never
change these?  And the rights they provide would be implicitly visible
in other APIs only exactly as Linux reflects effects of root's magic
rights?

The inside-the-library code that reads Windows ACLs would have to
filter to simply ignore these entries, the code that writes Windows
ACLs would have to merge/retain these entries as-is (possibly removing
one if a Posix-behaved entry for same SID were created, that seems a
choice you could make either way); might most everything else then
just fall out properly?


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