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 Apr 14 05:08, Bryan Berns wrote:
> On Tue, Apr 14, 2015 at 4:00 AM, Corinna Vinschen
> <corinna-cygwin@cygwin.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 :-(.

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.  


Corinna

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

Attachment: pgpeFCFQMPhel.pgp
Description: PGP signature


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