Bug 507574

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: