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=fZxjXACW79JJAuXFQjE8F8OkNzka9a0xQt6b6edLnAvoFIrMNY5PA
	7QgUvoGcusOcl7SlMI2kIvGGtH5D+eufc+P/u+NgzaT+DuGX4HyAYYkCJ8QU5uly
	UxSQQjHVzxxhFUEHyARhd66SmCesKYMori9UVBivn28IvmzEPE1FtY=
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=uLcE1lyezo3OMTJ2dtifoLdXkfg=; b=OKpa4obC3QY2un/mIsSzYKNiog8c
	9oC+c7Pub+c+iPDYKaDKuABSU3Z8V4+H0dalqxPVq2kaEC9bCm6/KN+lqGtnLoCf
	jEwk75A1vBHABSGY6OFIXQ3kGlbVcvHW9MDJSrJ2h2saY6jpxC7fL/Guff9PsMSy
	yyHCOC8ykzG8mSU=
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=-3.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,TBC autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Tue, 14 Apr 2015 11:23:13 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Making Cygwin More Tolerant of Orphaned SIDs?
Message-ID: <20150414092313.GE7343@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <CADi7v6LUZhr6UVSYA+Fe27f-aWJcxVxUXb3vR02rVuW9cG3a6A AT mail DOT gmail DOT com> <loom DOT 20150414T085644-392 AT post DOT gmane DOT org> <20150414080044 DOT GB7343 AT calimero DOT vinschen DOT de> <CADi7v6J=h7ydravvigVwMpT5P4QwMS1L73m1zhy==DtrL-SHhQ AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="ynll37MX3Fmyj3VY"
Content-Disposition: inline
In-Reply-To: <CADi7v6J=h7ydravvigVwMpT5P4QwMS1L73m1zhy==DtrL-SHhQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Apr 14 05:08, Bryan Berns wrote:
> On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen
> <corinna-cygwin AT cygwin DOT com> wrote:
> >
> > Orphaned SIDs shouldn't happen.  Disabling accounts, ok, but removing
> > them?  I don't know.  So the question is, if there's no account with
> > these SIDs anymore, why aren't these SIDs removed from the ACLs?
> > It's not only Cygwin.  These SIDs also unnecessarily slow down each
> > single access check of the OS.
> >
>=20
> In principal, I agree 100%.  Unfortunately, in some large enterprise
> environments removal of orphaned SIDs rarely happens on a regular
> basis.   The best way to manage this is typically to only delegate
> access via groups and have those groups aligned to the file system
> structure in some way (which tends to change less in practice than
> company organizational structure).  Still, when you've got dozens of
> people starting/leaving every week, per account permission are
> occasionally established enumerating more a petabyte of data across
> several sites to cleanup ACEs is certainly possible but not on the top
> list of things to do (and mass alteration of ACLs carries some
> liability to it).  Don't get me wrong, my anal retentive nature makes
> me cringe when I see an orphaned SID; it's just the reality of the
> situation.
>=20
> That said, the origin of my question was actually not due to
> unresolvable SIDs to due to removed accounts --- it was just the
> easiest one to describe. The reason I noticed this is because we have
> some NTFS assignments via local groups on a remote computers (and
> those local groups then have nested Active Directory groups).  So the
> ACE has REMOTECOMPUTER\Group vice DOMAIN\Group.  When Cygwin attempts
> to retrieve information on these accounts, it seems to fail and causes
> delays.  So with the newer versions of Cygwin, doing an 'ls -l' went
> from 2 seconds to more than 30 seconds on some particular file
> directories.
>=20
> As Achim alluded, 'noacl' may be be the way to go for us, but I was
> just asking the question in the even there was a configurable setting
> or a feature enhancement that could be integrated to deal with these
> scenarios.  Of course, 'noacl' seems to mark group / other masks as
> readable so apps that do permissions checks on these files will return
> inaccurate results :-(.

The problem is that Cygwin, or any other tool trying to resolve SIDs
doesn't know a SID won't resolve before it tried.  And then it's an
OS function which takes its time.  It's like checking for network
machines providing shares.  Sometimes this test takes ages, but in
this case, fortunately, you see that it takes ages in Explorer as
well.

As for ACLs, you can alleviate the problem somewhat by running cygserver
on the machine, which allows to cache SIDs for all processes.  So only
the first process trying the SID will take time, followup processes will
get the cached results from cygserver.

Other than that, except for ignoring ACLs entirely (noacl) I have
no idea how to solve this problem differently.=20=20


Corinna

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

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

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

iQIcBAEBAgAGBQJVLNyBAAoJEPU2Bp2uRE+gxw8P/0WQstW97nKF9vqyvXYPdLrF
uD6ANyQstasU8nalqK8omKdVR73OPxn0DPN9m4SiQyNdx9gYpPn191hP6d3Vp83i
Ri4UVQfHdgWjVEED1VjxTefO+OY4AJ17H6KI46eljJdi6rvNQdzL5kAzCpZhL/IS
dYj1tmJObnej6bBjbO6sif2fz740tNsF1AT3KGssWRdeA8s4aiTS46jfB50U/HkE
drz38UsZ1E5XdFhEJSKSriZx2abssk2fz0x8YBVi6bNGZzaiHHO5DU3utNNy2pIK
CFlrtwjLBi9GAwUAB35ogi3BKkkKWCqYHwgp8eX1paVqNs3Tx1rPU8d0Hc9Goc23
syHxdJL+UtoS9pTwm8CnAlHljKuoUSMZDllwGGfzW2yktox9RA+VGnpZmbIB7R9e
75Lujb3v5t0Z5Tfa/+Og6INN+qzDWywqDumAlDZvP8ElfrL5yEOnsPeQtTmu4vRk
aZ417Q+Mh0kYiuSTRvEnHIOEk9ITYAZJcVtjTf17Rapv018OkhuvJPnnp6HzVBem
s88UmKFrClGyBkHG55wVDh9dwwRpqkUumVvN8q/2PazEbLpf6RU9QiTFxfc5qVx9
ZuIEi8AhaQWoMh/zESiiRX26aDIPuMGTdZocPeTXqIdRrLJJQItEOL2ce8Yrc9zy
Q/xex350eru0+4d0Zi9M
=5it7
-----END PGP SIGNATURE-----

--ynll37MX3Fmyj3VY--