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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=Bz
	vkvlKMww86y2wSxRLv7ZIvklaF54+I7w7zRUxKImXzyNIlPaSKH2tWD7DvzbGSMH
	L+z5UhepjapngGCQ8Ff0Ow8/v+H+USa5QyOEWbDmirsQc5pqQkaZxtH1x/lr19dz
	xnLRUrGIb6fEaJwgZVGmCv6yNZeVcFplh9m0so/Ys=
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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=5uSJuMVM
	amW66byCILoqaksX28I=; b=Nt/KiME2yD0MdQ4RN3FRP1licLWibfbDN605ygR9
	ocnPZ5n2BAdn2+hWhMToVoDa14DZDme6kd/f2/ZQuKIw548RDHf3xOkcNm5iXVCY
	VlfasjQINpxZ1zewO/zV6MMqpGR12FVn/DzQT/ADNIsoVxUfISfumVecUMr1Z6qS
	co8=
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=-0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-la0-f50.google.com
MIME-Version: 1.0
X-Received: by 10.152.238.43 with SMTP id vh11mr17096780lac.45.1429002498713; Tue, 14 Apr 2015 02:08:18 -0700 (PDT)
In-Reply-To: <20150414080044.GB7343@calimero.vinschen.de>
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>
Date: Tue, 14 Apr 2015 05:08:18 -0400
Message-ID: <CADi7v6J=h7ydravvigVwMpT5P4QwMS1L73m1zhy==DtrL-SHhQ@mail.gmail.com>
Subject: Re: Making Cygwin More Tolerant of Orphaned SIDs?
From: Bryan Berns <bryan DOT berns AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes

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

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.

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.

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 :-(.

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