Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1193759
Description of problem: The extdom plugin of IPA does not handle large groups correctly, causing lookup failures for users and groups. It sets the buffer size for the getgrgid_r call to the suggested initial value from _SC_GETGR_R_SIZE_MAX, but does not check for an ERANGE return code for when for the buffer is too small. This results in an LDAP_OPERATIONS_ERROR as logged on the IPA server and incomplete group information on the IPA clients. In RHEL 7.0, this just resulted in large groups not getting a name associated with it on the clients. However, in RHEL 7.1 with the EXTDOM_V1 call, users that are members of these large groups fail completely and do not exist on the clients because all their groups are being looked up now. Setting a much larger buffer (e.g., 1048576) resolves this issue, but is not an elegant solution. There should be logic added to the getgrgid_r calls that gradually increase the buffer length until a maximum value is reached. See the "Additional info" section below for an example implementation. I have attached a script to re-create a large number of users for testing. Also attached is a patch statically increasing the buffer size so that we are clear on exactly where the issue lies. I am not a C programmer, so I wanted to leave a proper implementation up to the IPA developers. A similar patch is currently working around this issue for me in 3 separate environments who have now grown enough to be hitting this bug. I have a test environment that I setup tonight that allowed me to easily create this reproducer. Version-Release number of selected component (if applicable): ipa-server-trust-ad-4.1.0-10.el7.x86_64 How reproducible: always, problem exists upstream, RHEL 7.0 and RHEL 7.1 beta Steps to Reproduce: 1. setup an IPA/AD trust (RHEL 7.1 beta and 2012R2 in this reproducer, but reproducable on RHEL 7.0 with 2008R2 as well) 2. enable POSIX attributes in AD 3. set a GID for the 'Domain Users' group in AD 4. create a large number of users (see attached script named "add-users.sh") 5. create another group and set a GID for it 6. add all the test users to this new group (by name, do not nest 'domain users') 7. verify users exist on the IPA server (e.g., id test1@example.com) 8. setup an IPA client 9. attempt to run "id" on the user on the IPA client Actual results: [root@client01 ~]# id test1@example.com id: test1@example.com: no such user dirsrv access log: conn=1 op=5 EXT oid="2.16.840.1.113730.3.8.10.4.1" name="IPA trusted domain ID mapper" conn=1 op=5 RESULT err=1 tag=120 nentries=0 etime=0 Expected results: [root@client01 ~]# id test1@example.com uid=10000(test1@example.com) gid=10000(domain users@example.com) groups=10000(domain users@example.com),10001(biggroup@example.com) dirsrv access log: conn=33 op=13 EXT oid="2.16.840.1.113730.3.8.10.4.1" name="IPA trusted domain ID mapper" conn=33 op=13 RESULT err=0 tag=120 nentries=0 etime=0 Additional info: - GETGRNAM(3), see the end of the DESCRIPTION section for what _SC_GETGR_R_SIZE_MAX means and how to handle it - http://tomlee.co/2012/10/problems-with-large-linux-unix-groups-and-getgrgid_r -getgrnam_r/ for example code on handling a return value of ERANGE
master:[[BR]]
ipa-4-1:[[BR]]
Metadata Update from @mkosek: - Issue assigned to sbose - Issue set to the milestone: FreeIPA 4.1.4
Login to comment on this ticket.