This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Making Cygwin More Tolerant of Orphaned SIDs?

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.

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

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

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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]