Bug 867473 - Always include sss in /etc/nsswitch.conf
Always include sss in /etc/nsswitch.conf
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Law
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 980861 1000348 1000349
  Show dependency treegraph
 
Reported: 2012-10-17 11:17 EDT by Stef Walter
Modified: 2016-11-24 07:33 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 980861 1000348 (view as bug list)
Environment:
Last Closed: 2014-08-22 15:32:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
f18 branch: Include sss in nsswitch.conf by default (1.94 KB, patch)
2012-10-22 07:59 EDT, Stef Walter
no flags Details | Diff
f19 branch: Include sss in nsswitch.conf by default (1.96 KB, patch)
2012-10-22 09:14 EDT, Stef Walter
no flags Details | Diff

  None (edit)
Description Stef Walter 2012-10-17 11:17:33 EDT
In Fedora 17 and 18 we have a problem where remote users are unable to log in until the machine has been rebooted. This used to work previously. To fix this we probably need to:

Include 'sss' in /etc/nsswitch.conf by default and have the small sssd-client package (with just thepam, nss plugins) installed on all but minimal Fedora installs.

This happens after configuration using authconfig to change /etc/nsswitch.conf (or doing it manually). The changes are not picked up by long running processes like dbus-daemon --system. As far as I can see dbus-daemon then refuses to allow connections from these users. As might be expected, gnome-shell crashes hard when this happens.

There are some other ways to fix this problem, but these do not scale to fix the problem for every possible affected process:

http://sourceware.org/bugzilla/show_bug.cgi?id=12459

I'm filing this against the authconfig component, but in reality I think it affects more things like comps and anaconda.


TEST CASE:

* This should be ideally run on a freshly installed system or at
  least a system without sss in /etc/nsswitch.conf since last boot.

$ grep sss /etc/nsswitch.conf && "ALREADY HAVE sss"
$ sudo -s
# yum install sssd-tools pamtester
# test -f /etc/sssd/sssd.conf && mv /etc/sssd/sssd.conf /etc/sssd/sssd.conf.bak
# echo -e "[sssd]\ndomains=local\nconfig_file_version=2\nservices=nss,pam\n[domain/local]\nid_provider=local" > /etc/sssd/sssd.conf
# chmod 0600 /etc/sssd/sssd.conf
# systemctl start sssd.service
# authconfig --update --enablesssd --enablesssdauth
# sss_useradd --uid=2121 --gecos=Zapp zapp
# passwd zapp # set password for zapp
# pamtester zapp authenticate   # type password, should succeed

* Now go to gdm by logging out or switch user.
* Try to log in as zapp.
* Hang.
* Reboot
* Try to log in as zapp.
* Success
Comment 1 Stephen Gallagher 2012-10-19 10:39:04 EDT
Stef, this worked previously because Ray and I hacked GDM to call out to the 'id' command in a separate process to look up the users. This worked around the fact that changes to nsswitch.conf weren't applied to running processes.

However, this always basically hid the fact that it wasn't updating systemd, messagebus etc.

This bug doesn't belong to authconfig. It should be reassigned to glibc. There are two ways to fix it. One is to have the Fedora package ship 'sss' as you suggest.

The better solution would be for glibc to provide a mechanism for nsswitch.conf to be reread somehow, though this has been suggested in the past and rebuffed before, because it would require either polling or an inotify watch on the file (or else checking the file directly on every lookup, thereby slowing ID lookups down significantly.

So I suppose a temporary solution would be to put 'sss' in the default config. It will have no effect if SSSD is not installed or not running. (I have tested this just now).
Comment 2 Stef Walter 2012-10-22 05:36:35 EDT
Jeff, I'm trying to generate a patch for this. Wondering where glibc-2.16-75f0d304-fedora.tar.gz comes from? It contains the default nsswitch.conf. Is it in git somewhere?

Or should I instead make a patch?
Comment 3 Stef Walter 2012-10-22 07:59:02 EDT
Created attachment 631443 [details]
f18 branch: Include sss in nsswitch.conf by default

This is a patch to the f18 glibc fedora package.
Comment 4 Stef Walter 2012-10-22 09:14:28 EDT
Created attachment 631478 [details]
f19 branch: Include sss in nsswitch.conf by default

This is a patch to the f19 glibc fedora package
Comment 5 Jeff Law 2012-10-22 11:26:05 EDT
Stef,

As far as I can tell neither patch does what you claim it does.  You claim it adds "sss" to nsswitch.conf.  However, both patches simply remove passwd, shadow, group, services and netgroup from nsswitch.conf and do not add sss anywhere.
Comment 6 Stef Walter 2012-10-22 11:39:50 EDT
(In reply to comment #5)
> As far as I can tell neither patch does what you claim it does.  You claim
> it adds "sss" to nsswitch.conf.  However, both patches simply remove passwd,
> shadow, group, services and netgroup from nsswitch.conf and do not add sss
> anywhere.

There's something very strange going on with bugzilla.redhat.com here. It somehow modified my patches.

These are the patches I attached, and can be accessed by clicking on the big descriptive links under the 'Attachments' column in the table above. 

For f18: https://bugzilla.redhat.com/attachment.cgi?id=631443

For f19: https://bugzilla.redhat.com/attachment.cgi?id=631478

I have no idea what's going on with the munged patches linked from in comments 3 and 4. :S
Comment 7 Jeff Law 2012-10-22 11:51:11 EDT
It's the &action=diff appearing on the link in c#3 and c#4 that triggers the problem.   No clue why though.  They're referencing the same underlying attachment, BZ just munges them.

I'll add these to Fedora.   We already ship a hacked up nsswitch.conf, so this isn't really going to add to our long term maintenance cost.


Jeff
Comment 8 Jeff Law 2012-10-22 12:07:04 EDT
nsswitch.conf for F18 and rawhide has been updated.  Builds will spin today.
Comment 9 Ray Strode [halfline] 2012-10-25 10:39:35 EDT
note nss-mdns munges /etc/nsswith.conf hosts line to put

 mdns4_minimal [NOTFOUND=return]

on it (in %post).  Two thoughts:

1) is [NOTFOUND=return] important for sss too?
2) Should nsswitch.conf include mdns4_minimal by default as well?
Comment 10 Stef Walter 2012-10-26 15:46:02 EDT
(In reply to comment #9)
> note nss-mdns munges /etc/nsswith.conf hosts line to put
> 
>  mdns4_minimal [NOTFOUND=return]
> 
> on it (in %post).  Two thoughts:
> 
> 1) is [NOTFOUND=return] important for sss too?

Why? First of all it's last in the list. And secondly, why would we want to not continue to other modules sss returns NOTFOUND?

> 2) Should nsswitch.conf include mdns4_minimal by default as well?

mdns4_minimal [NOTFOUND=return] breaks domains that end in .local, at least it used to. libnss_sss has been designed to not have any impact if sssd is not running, is that the case for libnss_mdns4_minimal?
Comment 11 Fedora Update System 2012-11-17 00:03:16 EST
glibc-2.16-24.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/glibc-2.16-24.fc18
Comment 12 Fedora Update System 2012-11-26 23:51:12 EST
glibc-2.16-24.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 13 Dennis Gilmore 2014-08-19 12:09:01 EDT
I have had to revert the change to nsswitch.conf to workaround an issue causing livecd composes to fail due to the sssd nss library being loaded from the image into the compose process and being unable to successfully compose the Workstation Live
Comment 14 Simo Sorce 2014-08-19 12:20:42 EDT
Can you be more specific ?
I am not aware of any issues caused by the nss_sss module
Comment 15 Stephen Gallagher 2014-08-19 12:29:52 EDT
To summarize the discussion we had on IRC just now:

The issue is not specifically with the 'sss' module itself. The issue is that the 'sss' module is lazy-loaded only inside the compose chroot. This results in the system being unable to cleanly unmount the composed filesystem.

There's no inherent bug in the sss module itself, just an unfortunate interaction with other aspects of the compose process.

It's also speculated that this is fallout from the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1089738 as well.
Comment 16 Stephen Gallagher 2014-08-19 17:00:17 EDT
(In reply to Dennis Gilmore from comment #13)
> I have had to revert the change to nsswitch.conf to workaround an issue
> causing livecd composes to fail due to the sssd nss library being loaded
> from the image into the compose process and being unable to successfully
> compose the Workstation Live

I'd like to respectfully request that you restore the old behavior and instead implement the workaround I've proposed in https://bugzilla.redhat.com/show_bug.cgi?id=1127103.
Comment 17 Dennis Gilmore 2014-08-19 22:42:15 EDT
the suggested workaround is not implementable. it needs patches in livecd-creator
Comment 18 Simo Sorce 2014-08-20 08:30:50 EDT
Please let's find another workaround, this revert reintroduces a big regression, we have now software counting and depending on sss being already in nsswitch.conf
Comment 19 Dennis Gilmore 2014-08-22 15:32:07 EDT
I've patched the compose tools to preload the sss nss library. and ive added sss back to the default nsswitch.conf file.

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