Bug 1128612

Summary: IFP: FQDN lookups are broken
Product: Red Hat Enterprise Linux 6 Reporter: Jakub Hrozek <jhrozek>
Component: sssdAssignee: Jakub Hrozek <jhrozek>
Status: CLOSED ERRATA QA Contact: Kaushik Banerjee <kbanerje>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.0CC: 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
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/2402

With the current IFP code, a fully qualified lookup doesn't work:
{{{
dbus-send --print-reply \                                                                                                                                                                                         
           --system \                                                                                                                                                                                              
           --dest=org.freedesktop.sssd.infopipe \                                                                                                                                                                  
           /org/freedesktop/sssd/infopipe \                                                                                                                                                                        
           org.freedesktop.sssd.infopipe.GetUserGroups string:user@domain             
}}}

There is already a patch on the list, this ticket is mostly a tracking one.

Comment 5 Jakub Hrozek 2014-08-11 13:38:26 UTC
Fixed upstream:
    master: d8b8995ef1c3f2a6c85dc141aaff7eef3faf05c1
    sssd-1-11: 6a8ffd54cac6ede65e815b80c04ddd3996706a60

Comment 6 Jakub Hrozek 2014-08-11 13:40:10 UTC
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.

Comment 7 Jan Pazdziora 2014-08-11 14:04:11 UTC
(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?

Comment 8 Jan Pazdziora 2014-08-11 14:12:04 UTC
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.

Comment 9 Jakub Hrozek 2014-08-11 14:27:56 UTC
(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.

Comment 10 Jan Pazdziora 2014-08-12 08:36:37 UTC
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"
            ]
      )
   ]

Comment 11 Jakub Hrozek 2014-08-12 11:36:33 UTC
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

Comment 12 Jan Pazdziora 2014-08-12 12:18:05 UTC
(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.

Comment 16 Kaushik Banerjee 2014-09-10 11:49:50 UTC
Marking the bug verified SanityOnly with version 1.11.6-29. Existing automation runs passes.

Comment 17 errata-xmlrpc 2014-10-14 04:49:29 UTC
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