Bug 1128612 - IFP: FQDN lookups are broken
Summary: IFP: FQDN lookups are broken
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-11 08:10 UTC by Jakub Hrozek
Modified: 2014-10-14 04:49 UTC (History)
12 users (show)

Fixed In Version: sssd-1.11.6-16.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-14 04:49:29 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1375 normal SHIPPED_LIVE sssd bug fix and enhancement update 2014-10-14 01:06:25 UTC

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@EXAMPLE.TEST array:string:mail
method return sender=:1.19 -> dest=:1.83 reply_serial=2
   array [
      dict entry(
         string "mail"
         variant             array [
               string "bob23392@example.test"
            ]
      )
   ]

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


Note You need to log in before you can comment on or make changes to this bug.