Bug 507574 - dbus-daemon seems to not like it if nsswitch.conf changes
dbus-daemon seems to not like it if nsswitch.conf changes
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: dbus (Show other bugs)
12
All Linux
high Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 513462
  Show dependency treegraph
 
Reported: 2009-06-23 07:10 EDT by Colin.Simpson
Modified: 2013-03-05 22:58 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:48:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Colin.Simpson 2009-06-23 07:10:43 EDT
Description of problem:
We have a Network Manager dispatcher script that replaces nsswitch.conf after it detects if we are on the corporate network or not (e.g password: line changes from "files" to "files ldap" etc etc), in order to use the LDAP directory service for user info. 

Using this script with F11 results in network users being unable to login into the GUI. This seems related to dbus-daemon as restarting the messagebus service (after networking is up) works fine (well dependent services are still screwed but GUI login works). I'd imagine the same problem will arise with editing (manually or authconfig) nsswitch.conf after the system is up. Another workaround we have is to move nscd up to starting at S20nscd before S22messagebus, this seems to make dbus more dynamic to changes in the nss system (not too surprisingly), then everything works. 

We know it's name service related as if you put the network user's (LDAP) info into the passwd file, GUI login works fine. 

This is a change from F10. Is there more security on the new version or something that it requires userinfo to be available to the dbus-daemon? 
May not be a massive issue for a lot of users but maybe indicative of another issue.

Version-Release number of selected component (if applicable):


How reproducible:
Everytime

Steps to Reproduce:
1.Boot with nsswitch.conf with only file
2.Change to "files ldap" in passwd, shadow, group entries in nsswitch.conf, maybe then an nscd -i passwd , then group etc or an nscd restart I guess.
3.Try to login
  
Actual results:
Jun 22 12:57:50 localhost gnome-keyring-daemon[2828]: error connecting to D-BUS system bus: Did not receive a reply. Possible causes include: the remote appl
ication did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Jun 22 12:57:50 localhost gnome-keyring-daemon[2828]: Scheduling hal init retry
Jun 22 12:57:53 localhost gnome-session[2986]: WARNING: Could not connect to ConsoleKit: Did not receive a reply. Possible causes include: the remote applica
tion did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Jun 22 12:57:53 localhost gnome-session[2986]: CRITICAL: dbus_g_connection_get_connection: assertion `gconnection' failed
Jun 22 12:57:53 localhost gdm[2990]: ******************* START **********************************
Jun 22 12:57:54 localhost gdm[2990]: [Thread debugging using libthread_db enabled]
Jun 22 12:57:54 localhost gdm[2990]: 0x0000003ec6ca3a1e in waitpid () from /lib64/libc.so.6
Jun 22 12:57:54 localhost gdm[2990]: #0  0x0000003ec6ca3a1e in waitpid () from /lib64/libc.so.6
Jun 22 12:57:54 localhost gdm[2990]: #1  0x00000000004187d3 in gtk_tree_model_iter_n_children ()
Jun 22 12:57:54 localhost gdm[2990]: #2  0x0000000000418887 in gtk_tree_model_iter_n_children ()
Jun 22 12:57:54 localhost gdm[2990]: #3  <signal handler called>
Jun 22 12:57:54 localhost gdm[2990]: #4  0x0000003ec6c332f5 in raise () from /lib64/libc.so.6
Jun 22 12:57:54 localhost gdm[2990]: #5  0x0000003ec6c34b20 in abort () from /lib64/libc.so.6
Jun 22 12:57:54 localhost gdm[2990]: #6  0x0000003ece42a435 in ?? () from /lib64/libdbus-1.so.3
Jun 22 12:57:54 localhost gdm[2990]: #7  0x0000003ece42629d in ?? () from /lib64/libdbus-1.so.3
etc

Expected results:
A clean login

Additional info:
Comment 1 Bug Zapper 2010-11-04 07:01:33 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Bug Zapper 2010-12-05 01:48:59 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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