On Thu, 2015-05-14 at 17:11 -0400, James Ralston wrote:
On Wed, May 6, 2015 at 3:10 PM, Stephen Gallagher <
> To be fair, it's not that hard to turn that [ldapsearch command]
> into a bash script that your users can use instead of learning the
> ldap syntax. But yes, that's still a change in behavior.
We could, but I think just using the ldapsearch command would cause
less confusion in the long run.
> Well, as the original post to this list noted, this is already
> broken, with no way to fix it. When we're talking to LDAP, there's
> no guarantee that the server will actually let us get all of the
> results. Many servers are configured with a limited number of
> records we can retrieve (though we work around that with paging
> controls on servers that support them). With AD, we can only
> enumerate the domain the host is joined to. If your users aren't
> part of the same domain as the host, enumeration won't find them.
I get it: there are multiple reasons why enumeration might not work
a particular environment, and it might not be obvious (until you try
it) whether it will work.
But it *does* work for us. And it works for others.
Does it really make sense to remove a useful feature just because
there are corner cases in which it doesn't work?
(Hell, more than half of the Linux kernel code would have to be
excised if that's the standard we're using.)
I mean, how much time are the sssd developers spending fielding
complaints about enumeration not working correctly? If the answer is
"little to none", and the limitations are clearly spelled out (which
they are), what harm is there in leaving it enabled?
Well, the SSSD developers are spending a moderate amount of time
dealing with bugs in it, first of all. Secondly, the limitations aren't
really clearly spelled out. We probably need to expand the manpages to
describe how poorly this feature works. Right now, it only describes
the negative performance impact, but not the fact that it simply
doesn't work in some environments.
And the harm to leaving it enabled is that failures in the enumeration
code are generally *silent* and therefore hard to debug. When an
enumeration only completes partially, there's no way to know. If you
have a system that is basing access control on a user being in (or not
in) a particular group read through enumeration, then this may result
in a security issue. (Example: you explicitly disallow members of the
"untrusted" group from accessing sensitive machines. However, user
jappleseed should be in this group, but enumeration didn't pick him up
because of a peculiarity of cross-realm interaction. Now jappleseed has
access to a sensitive machine. Ouch.)
> > [W]e have many systems that cannot be joined to Active
> > (for policy reasons, not technical reasons).
> Sorry to sound glib, but "fix your policy". Let's be honest, any
> policy that boils down to "These machines are not allowed to
> function with proper security controls" is one that can only end in
Actually, the policy is a component of proper security controls.
(Which is why the policy won't change.)
If they cannot be joined to an existing Active Directory domain, why
can't they be joined to an isolated AD or FreeIPA domain? That's
probably irrelevant to the current conversation, though.
> > I'm not asking you to make enumeration the default. It
> > be; it should be something you only turn on if you need it, and
> > you KNOW you need it. But if you need it, you NEED it. Please
> > don't take it away.
> If you need it, you're already in bad shape. Have you heard the
> adage "If someone is irreplaceable, replace them immediately"? The
> same is true for software. If you have a bad system in place, it's
> best to rip it out as fast as possible, because otherwise the
> problem will continue to grow, accruing technical debt you can
> hope to manage.
Let me rephrase: to us, enumeration is a highly desirable feature,
sssd nicely provides that feature.
Sure, I completely agree with you that *if it worked as advertised*, it
would be a really nice feature. The fact is that it doesn't. And in
some situations, we're discovering that it actually *can't* (and as
noted above, may not be able to warn you of this fact).
Could we survive if sssd removed enumeration? Yes. I could cobble
something together to perform a global LDAP search against AD,
the usernames and groupnames from the returned objects, and then
perform a bajillion getpwnam(3) and getgrnam(3) calls on the object
Well, I don't know the specific use-case here, but in most cases it's
more reliable to just get the list of groups a user belongs to (which
we *can* do reliably) and base decisions on that. Of course, this
doesn't work if your goal is a user/group browser.
But sssd already does that for us. And it does it more reliably,
less overhead, than whatever replacement I could throw together.
That's certainly fair, but again: which is worse?
1) Not having the ability to list all users
2) Being told that you can, but it might not work - without any way to
notify you that it failed.
> This is one of those cases: every band-aid we apply to the
> enumeration support causes this to limp along on life-support and
> provides consumers a false sense that this is something they can
> rely upon.
I would argue that enumeration *is* reliable: if it works for your
configuration, it will work each time, every time.
As long as your configuration doesn't change and start hitting one of
the cases we can't support. Example: you suddenly add your 2001st user
and don't notice that the LDAP server only allows clients to retrieve
2000 records. Enumerate will continue to appear to work, but it won't
be able to get all the records. (Bonus points: some LDAP servers don't
have a predictable order of which records you get back, so enumerate
might see a different view at different times.)
I think what you mean is, "enumeration will only work for
configurations". That's a fair statement, but it's not the same
It's not just certain configurations but it may be certain states
within an otherwise good configuration (such as the paging limitation I
noted just above).