From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9762 invoked by alias); 14 Apr 2015 09:23:17 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 9754 invoked by uid 89); 14 Apr 2015 09:23:17 -0000 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 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Apr 2015 09:23:16 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id D182DA807D2; Tue, 14 Apr 2015 11:23:13 +0200 (CEST) Date: Tue, 14 Apr 2015 09:23:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Making Cygwin More Tolerant of Orphaned SIDs? Message-ID: <20150414092313.GE7343@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20150414080044.GB7343@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ynll37MX3Fmyj3VY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg00296.txt.bz2 --ynll37MX3Fmyj3VY Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3212 On Apr 14 05:08, Bryan Berns wrote: > On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen > 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 Content-length: 819 -----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--