Bug 1128612 – IFP: FQDN lookups are broken

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 1128612 - IFP: FQDN lookups are broken

Summary:	IFP: FQDN lookups are broken

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	sssd (Show other bugs)
Sub Component:
Version:	6.0
Hardware:	Unspecified Unspecified

Priority	unspecified Severity unspecified
Target Milestone:	rc
Target Release:	---
Assigned To:	Jakub Hrozek
QA Contact:	Kaushik Banerjee
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2014-08-11 04:10 EDT by Jakub Hrozek
Modified:	2014-10-14 00:49 EDT (History)
CC List:	12 users (show)

See Also:
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 00:49:29 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2014:1375	normal	SHIPPED_LIVE	sssd bug fix and enhancement update	2014-10-13 21:06:25 EDT

Groups: None (edit)

Description Jakub Hrozek 2014-08-11 04:10:22 EDT

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 09:38:26 EDT

Fixed upstream:
    master: d8b8995ef1c3f2a6c85dc141aaff7eef3faf05c1
    sssd-1-11: 6a8ffd54cac6ede65e815b80c04ddd3996706a60

Comment 6 Jakub Hrozek 2014-08-11 09:40:10 EDT

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 10:04:11 EDT

(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 10:12:04 EDT

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 10:27:56 EDT

(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 04:36:37 EDT

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 07:36:33 EDT

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 08:18:05 EDT

(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 07:49:50 EDT

Marking the bug verified SanityOnly with version 1.11.6-29. Existing automation runs passes.

Comment 17 errata-xmlrpc 2014-10-14 00:49:29 EDT

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.