Learn more about these different git repos.
Other Git URLs
Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1139044
Description of problem: In IPA on RHEL6, I see errors logging in as a user: [root@ipa slapd-EXAMPLE-COM]# ssh -l ipauser1 $(hostname) ipauser1@ipa.example.com's password: Could not chdir to home directory /home/ipauser1: No such file or directory id: cannot find name for group ID 982000001 -sh-4.1$ exit From sssd log (from IPA client here) I see: (Sun Sep 7 13:50:26 2014) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=ipauser1)(objectclass=groupofname s)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=accounts,dc=example,dc=com]. Checking the group info in IPA: [root@ipa slapd-EXAMPLE-COM]# ipa group-show ipauser1 --all --raw dn: cn=ipauser1,cn=groups,cn=accounts,dc=example,dc=com cn: ipauser1 description: User private group for ipauser1 gidnumber: 982000001 ipauniqueid: bbef789c-36be-11e4-a38e-0000c0a87a65 mepmanagedby: uid=ipauser1,cn=users,cn=accounts,dc=example,dc=com objectclass: posixgroup objectclass: ipaobject objectclass: mepManagedEntry objectclass: top I do not see objectclass groupofnames. If I add that, I can start seeing user private group: [root@ipa slapd-EXAMPLE-COM]# ldapmodify -D "cn=Directory Manager" -w Secret123 <<EOF dn: cn=ipauser1,cn=groups,cn=accounts,dc=example,dc=com add: objectClass objectClass: groupofnames EOF modifying entry "cn=ipauser1,cn=groups,cn=accounts,dc=example,dc=com" [root@ipa slapd-EXAMPLE-COM]# getent group ipauser1 ipauser1:*:982000001: [root@ipa slapd-EXAMPLE-COM]# ssh -l ipauser1 $(hostname) ipauser1@ipa.example.com's password: Last login: Sun Sep 7 14:08:14 2014 from ipa.example.com Could not chdir to home directory /home/ipauser1: No such file or directory -sh-4.1$ Version-Release number of selected component (if applicable): ipa-server-3.0.0-42.el6.x86_64 sssd-1.11.6-29.el6.x86_64 How reproducible: always Steps to Reproduce: 1. On RHEL6.6 server setup IPA server wtih DNS (ipa-server-install --setup-dns --forwarder=<IP> ...) 2. ipa user-add ipauser1 --first=f --last=l --password 3. kinit ipauser1 # set password 4. getent group ipauser1 5. ssh -l ipauser1 $(hostname) Actual results: cannot see user private group for ipauser1. Expected results: can see upg for ipauser1 without having to add groupaddnames manually Additional info:
regression -> blocker. Michal has a WIP patch.
blockedby: => blocking: => changelog: => coverity: => design: => design_review: => 0 feature_milestone: => fedora_test_page: => priority: major => blocker review: True => 0 selected: => testsupdated: => 0
confirmed I'm seing this on a test F21-on-F21 (client and server) deployment , though strangely not on my production deployment with F19 server but F21 client. Probably a candidate for F21 freeze exception, I'll file a downstream bug.
In the case that works, groupofnames does not match on my user's private group, but does match on a couple of other non-private groups - perhaps as long as some group matches the groupofnames check, the user's private group is picked up later and the bug is hidden? Anyway, I definitely confirm it in a clean deployment using ipa user-add and not using any supplementary groups.
https://bugzilla.redhat.com/show_bug.cgi?id=1139962 for F21 Alpha.
Replying to [comment:3 adamwill]:
On IPA server, regular POSIX group (added with ipa group-add) have both posixGroup and groupOfNames, regular non-POSIX groups have only groupOfNames and user private groups only carry posixGroup.
So we need to have a way on the client to match several object classes for the same object type which we haven't done before.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1139962 (Fedora)
rhbz: [https://bugzilla.redhat.com/show_bug.cgi?id=1139044 1139044] => [https://bugzilla.redhat.com/show_bug.cgi?id=1139044 1139044], [https://bugzilla.redhat.com/show_bug.cgi?id=1139962 1139962]
Actually, correction: after a reboot, I'm seeing this bug in my production deployment too (the one where my user is a member of some other groups). So I guess it was a regression in a recent sssd update, either 1.12.1-1 or 1.12.0-7 ?
[adamw@adam live]$ id uid=1001(adamw) gid=1001 groups=1001,491(mock),157400008(sysadmins) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
note there's no name associated with group 1001. Found my first practical consequence of this too - virt-manager won't work:
Unable to connect to libvirt. Failed to find group record for gid '1001'
edit: For F21 this looks like a regression in 1.12.1-1 . I downgraded all packages to 1.12.0-7.fc21 , restarted sssd , logged in on a VT and that login has correct 'id' output.
_comment0: Actually, correction: after a reboot, I'm seeing this bug in my production deployment too (the one where my user is a member of some other groups). So I guess it was a regression in a recent sssd update, either 1.12.1-1 or 1.12.0-7 ?
{{{ [adamw@adam live]$ id uid=1001(adamw) gid=1001 groups=1001,491(mock),157400008(sysadmins) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 }}}
{{{ Unable to connect to libvirt.
Failed to find group record for gid '1001' }}} => 1410402622800809
Patch is on review.
owner: somebody => mzidek patch: 0 => 1
milestone: NEEDS_TRIAGE => SSSD 1.11.7 resolution: => fixed status: new => closed
Metadata Update from @jhrozek: - Issue assigned to mzidek - Issue set to the milestone: SSSD 1.11.7
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3478
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.