public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Making Cygwin More Tolerant of Orphaned SIDs?
Date: Tue, 14 Apr 2015 09:23:00 -0000	[thread overview]
Message-ID: <20150414092313.GE7343@calimero.vinschen.de> (raw)
In-Reply-To: <CADi7v6J=h7ydravvigVwMpT5P4QwMS1L73m1zhy==DtrL-SHhQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3265 bytes --]

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 #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-04-14  9:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-14  3:58 Bryan Berns
2015-04-14  6:57 ` Achim Gratz
2015-04-14  8:00   ` Corinna Vinschen
2015-04-14  9:08     ` Bryan Berns
2015-04-14  9:23       ` Corinna Vinschen [this message]
2015-04-14 11:24         ` Bryan Berns
2015-04-14 12:31           ` Noel Grandin
2015-04-14 14:54             ` Corinna Vinschen
2015-04-14 15:00               ` Corinna Vinschen
2015-04-14 14:53           ` Corinna Vinschen
2015-04-14 16:21             ` Corinna Vinschen
2015-04-14 16:45             ` Bryan Berns
2015-04-14 18:23               ` Corinna Vinschen
2015-04-15  1:23                 ` Bryan Berns
2015-04-15  7:29                   ` Corinna Vinschen
2015-04-15  9:44                     ` Bryan Berns
2015-04-15 15:44                       ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150414092313.GE7343@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).