On Thu, 2015-05-14 at 17:11 -0400, James Ralston wrote:
On Wed, May 6, 2015 at 3:10 PM, Stephen Gallagher < sgallagh@redhat.com> wrote:
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 in 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 Directory (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 disaster.
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 shouldn't 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 never hope to manage.
Let me rephrase: to us, enumeration is a highly desirable feature, and 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, extract the usernames and groupnames from the returned objects, and then perform a bajillion getpwnam(3) and getgrnam(3) calls on the object names.
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, with 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 certain configurations". That's a fair statement, but it's not the same thing as "unreliable".
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).