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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=l6Abd4I2ajqHUN8DbyUojFSw2A5T45R5kO6MNY72y+NbZkfzCewah
	DLh8BDPCgRwDcqL8N/H7+D/f/OMbNG4skbMHYMKX2O4XPXATiO6uiHh1qJ5O8HPS
	TPorBpcE+sbutA1c7eW6SonX2fPFxAsnlUNjYivxQnGknPgifJx/Do=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=hs1rn5NpH9h2pOAHkd/cVrxo2Lc=; b=gMe8o4ZwGA+aGy+BzW94yflkzIx2
	lEYI70wj1F+zwfhzMYd8p/oY6Q5WRHgRTKFy9Gwhwq2SN1qWw9WKQq/XvNwRTchE
	ZFFO4QxolimjtBa7QBBE89japH2AUUaXjKhheaEzRnfywPDEckqz+eYcou+GZAyN
	flQ5eL5+/dX+d7Y=
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=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Wed, 12 Aug 2015 17:58:17 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: Shares with strange ACL settings
Message-ID:	<20150812155817.GN13029@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<loom DOT 20150811T101658-176 AT post DOT gmane DOT org> <20150812152601 DOT GL13029 AT calimero DOT vinschen DOT de> <loom DOT 20150812T172703-7 AT post DOT gmane DOT org>
MIME-Version:	1.0
In-Reply-To:	<loom.20150812T172703-7@post.gmane.org>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

On Aug 12 15:50, Achim Gratz wrote:
> Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:
> > I don't know what to do about this.  We're talking back and forth
> > about reflecting group perms into user perms and whether we do it
> > or not, it always seems to have some downside on some installations.
>=20
> Since there are fundamental differences between how Windows evaluates ACL
> vs. what POSIX expects this problem isn't going away anytime soon.=20
> Depending on how much control you have over the default or inherited ACL =
you
> can pretend these differences are non-existing with varying degrees of
> success.  Another fly in that ointment are the Backup/Restore privileges,
> but these you can control if you are aware of them.

Cygwin is aware of them and access(2) explicitely checks for them.  That
obviously doesn't help for applications like perl, who "know better"
than the underlying OS how to evaluate perms.

> > > So, it would probably help if I had a mount option to force the owner=
ship to
> > > some account that I am never logged in as, either via a mount option =
or
> > > whenever the POSIX user modes are all cleared.  I don't know if that =
might
> > > confuse applications when they check ownership on newly created files,
> > > though.  Is that something that is implementable easily so it could be
> > > tested via a snapshot?
> >=20
> > I'm not sure I understand the idea of mounting w/ an explicit user acco=
unt
> > and how this might help.  What about just using the noacl mount option
> > for weird shares like the above?
>=20
> That mount option would ensure that the ACL are actually consulted by a
> POSIX application when the user mode bits are all cleared since the file
> would appear not to be owned by the (E)UID.  The only other option I can =
see
> would be to augment stat to traverse the DACL when both these conditions =
are
> met: the file is owned by the (E)UID of the calling process and the user
> mode bits are all cleared.  That is, do the faccessat on behalf of the
> application that it would otherwise (likely) do if the file was _not_ own=
ed
> by the user.  Of course you can't really know why stat was called and that
> might impact perfromance quite noticeably.

It does.  Another, *very* simple idea is this:  Spill the group and
other perms into the user bits only if the owner of the file is the
current user.  Would that help?

> As to "why not use the noacl option", that makes the file mode tests
> completely useless and requires more elaborate error handling that would
> otherwise not be necessary.  Some users and scripts they have written are
> not prepared for that extra complication.

But there's no additional checking necessary because the perms are
guarded by the OS anyway.  The applications just don't know them exactly.


Corinna

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

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

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

iQIcBAEBCAAGBQJVy20ZAAoJEPU2Bp2uRE+g5eMP/iqbOUHouGuAeK+VZ6MQJEk6
vP0eDhvo28TKqXWXHPa8amnldMFd/jnFm9f+qIoM+sok4kywrtNT4QhCtSV5mokP
rfF7O6091YXSDX1oOwtQl+6nhhH7xSVN+TY0LUrlK5IN3ZbmCzFAAsDZWfzd7tSe
0I4palKB2lXDTY6uqR5j/dzlI/XKZHAo0DKXsMWj2zM6GEiXxoUuiSQzfh0kIx1W
x4bqbqzedxqaUriy2ZFJUr4FYVME4wNejINzkE9IAK/c2oqaa1WfcCnq4FEqLakM
rW6mE1GVwVMIcEvTdbmf+DgDKq8m9yHHvKoBVK5Oa5nXnjF/oD2fhEoFDxJEfR0z
t7sJH7H3Af/lXMacWsC1dDL5KwkRJ29cjKQQzVwoUoCnFiucWjqIy3MuQdUcqCF8
l4zdzc5llo/V+RKiw3suPlRwhztvYU/E903kXaiBKFTKMovUrx8uHajMwrblwVdw
qAiyzemVUTTeJaLrdOzKNKnMm3D8yAxw7VnwsHOxfqFrcpsJsuA7fKs4utlrIsEK
l2fkA8Z2AnKmn2TLfhMIYh2dpXJlHRZJFOWgb/wEeDvdEm7CP1k332lEAijDvAkK
mkqIvYh4zlKKbzOYpz8lFM1mT0WnlzoedxOlNDUSznHNyLwljS/QKhTWC8tbmX3f
uu4HKYy35wAo4RE86Oix
=n7+o
-----END PGP SIGNATURE-----

--cEobB2knsyc5ebfU--

- Raw text -