Bug 1128612
Summary: | IFP: FQDN lookups are broken | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jakub Hrozek <jhrozek> |
Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> |
Status: | CLOSED ERRATA | QA Contact: | Kaushik Banerjee <kbanerje> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.0 | CC: | dpal, grajaiya, jgalipea, jhrozek, jhutar, jpazdziora, kbanerje, lslebodn, mkosek, pbrezina, preichl, tlavigne |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | sssd-1.11.6-16.el6 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-10-14 04:49:29 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jakub Hrozek
2014-08-11 08:10:22 UTC
Fixed upstream: master: d8b8995ef1c3f2a6c85dc141aaff7eef3faf05c1 sssd-1-11: 6a8ffd54cac6ede65e815b80c04ddd3996706a60 If it's enough to test with dbus-send, then the following command invocation should do the trick: dbus-send --print-reply \ --system \ --dest=org.freedesktop.sssd.infopipe \ /org/freedesktop/sssd/infopipe \ org.freedesktop.sssd.infopipe.GetUserGroups string:user@domain The user visible part of the problem would appear if someone configured their sssd.conf with: use_fully_qualified_names=yes then sssd requires you to use logins in the form of "user@domain", not just "user" and that's where we fail. (In reply to Jakub Hrozek from comment #6) > > The user visible part of the problem would appear if someone configured > their sssd.conf with: > use_fully_qualified_names=yes > > then sssd requires you to use logins in the form of "user@domain", not just > "user" and that's where we fail. Even without use_fully_qualified_names=yes, would for example KrbLocalUserMapping Off in mod_auth_kerb configuration also demonstrate the issue? Is the reproducer supposed to be visible with GetUserAttr as well? I can't seem to get the faulty behaviour with sssd-dbus-1.12.0-1.el7.x86_64 and GetUserAttr. (In reply to Jan Pazdziora from comment #8) > Is the reproducer supposed to be visible with GetUserAttr as well? I can't > seem to get the faulty behaviour with sssd-dbus-1.12.0-1.el7.x86_64 and > GetUserAttr. Yes, the two methods share the same common (broken) code. Why does the following seem to work then?
# rpm -q sssd-dbus
sssd-dbus-1.12.0-1.el7.x86_64
# dbus-send --print-reply \
> --system \
> --dest=org.freedesktop.sssd.infopipe \
> /org/freedesktop/sssd/infopipe \
> org.freedesktop.sssd.infopipe.GetUserAttr string:bob23392 array:string:mail
method return sender=:1.19 -> dest=:1.83 reply_serial=2
array [
dict entry(
string "mail"
variant array [
string "bob23392"
]
)
]
Chances are bob is already cached with some other nsswitch call, maybe with getpwnam or id. The lookups works fine if the user was already cached, it's "just" not able to request a non-existant user from the back end. Can you try: service sssd stop rm -f /var/lib/sss/db/cache_* service sssd start dbus-send XXX (In reply to Jakub Hrozek from comment #11) > Chances are bob is already cached with some other nsswitch call, maybe with > getpwnam or id. The lookups works fine if the user was already cached, it's > "just" not able to request a non-existant user from the back end. > > Can you try: > > service sssd stop > rm -f /var/lib/sss/db/cache_* > service sssd start > dbus-send XXX Confirming. Thank you. By the way, when after that cleanup I first try to get GetUserAttr for the FQDN username, it fails (Error org.freedesktop.DBus.Error.Failed: No such user), and the subsequent GetUserAttr for local username fails with the same error message. Marking the bug verified SanityOnly with version 1.11.6-29. Existing automation runs passes. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1375.html |