GNOME Bugzilla – Bug 141138
gconf can't cope with UID change ...
Last modified: 2008-10-28 01:03:30 UTC
Change your UID, log out, log in - bang; misleading warning: michael@linux:~> gnome-session 2>&1 | tee /tmp/login-log GConf Error: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://www.gnome.org/projects/gconf/ for information. (Details - 1: IOR file '/tmp/gconfd-michael/lock/ior' not opened successfully, no gconfd located: Permission denied 2: IOR file '/tmp/gconfd-michael/lock/ior' not opened successfully, no gconfd located: Permission denied) ORBit2 can cope with changed UIDs just fine; we should really re-use it's code to save pain: The problem is, this means initializing ORBit2 earlier in the code; Either way - the brokenness is in: gconf/gconf/gconf-internals.c (gconf_get_daemon_dir): a simple fix would be to use the UID instead of the username in the directory name I guess.
See also bug #121217
*** Bug 121217 has been marked as a duplicate of this bug. ***
Here is a patch that searches in /tmp for a suitable directory, similar to ORBit.
Created attachment 30241 [details] [review] Patch to scan directories in /tmp and to create a suitable one if none is found.
Bumping the priority/severity as this is a potential DOS attack.
Okay, there are a number of issues: - We don't want the client to create the daemon dir if it doesn't exist, only the daemon should do that. See http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120664 - Even though gconf_get_daemon_dir() is creating the dir, we're still trying to create the dir in gconfd.c:main() - We also have a tmpdir testing function in gconfd.c already: test_safe_tmp_dir() - We should be using g_log() rather than g_warning() - All the g_error()s make me nervous - we should be trying to log an error to syslong and shutdown correctly - see gconfd.c:main() where we log "Failed to get lock for daemon" - That while (!safe_dir) is pretty confusing logic - wonder is there any way to clean that up (not hugely important)
I don't have time to work on this; does anybody want to pick it up?
So, here's what's happened in the meantime: - The patches in the redhat bugzilla report above have been applied. - gconf_get_daemon_dir() does not create the dir. The only place in gconf-internals.c I see a call to g_mkdir() is in gconf_get_lock_or_current_holder() which is called by gconf_get_lock(). - in main() we first create the dir manually by duplicating the same code that is in gconf_get_lock_or_current_holder() and then if that fails we call gconf_get_lock() later :-/
Like many if not most tough gconf issues, this one just goes away if someone fixes the bigger-picture design: http://www.gnome.org/projects/gconf/plans.html
Lowering pri and severity since this clearly can't be critical and urgent for years :-)
*** Bug 167030 has been marked as a duplicate of this bug. ***
See attachment 110602 [details] [review] from bug 507310 for a potential solution to this. (moving comment from bug 167030 since it was a duplicate of this bug)
2008-05-09 Ray Strode <rstrode@redhat.com> Tie gconf daemon to session bus and drop use daemon GetIOR() method instead of /tmp/something/ior to tell clients about ior (bugs 141138 and 507310) * configure.in: depend on dbus * gconf/gconfd.c (get_introspection_xml), (bus_message_handler), (get_on_d_bus), (main): Connect to message bus, take org.gnome.GConf name, and export GetIOR() method. Quit, when session quits. * Makefile.am: * gconf/org.gnome.GConf.server.in: new service file to support session bus activation * gconf/gconf-sanity-check.c (offer_delete_locks): Daemon doesn't have a lock anymore, so need to try to blow it away. * gconf/gcon-internals.c (read_current_server_and_set_warning), (read_current_server), (gconf_get_current_lock_holder), (gconf_daemon_blow_away_locks), (set_cloexec), (close_fd_func): dropped functions dealing with files in /tmp (get_ior), (gconf_get_server), (gconf_get_lock_or_current_holder), (gconf_activate_server: call GetIOR method instead of of reading /tmp/gconf-$USER/ior
Hmm - is that really what we want ? GConf was quite pleasantly shared per-system previously; writing settings may get a little mangled otherwise between concurrent sessions on the same machine. Also - it is (I guess) necessary to work around malicious users' creation of invalid directories in /tmp to clobber other users - does this deal with that ? Ultimately - I guess, we really want a single, known-safe, user-owned tmp directory to put such files in for the session (or system for that user).
So I don't *think* there should be any mangling going on. The backends are responsible for their own locking, and I didn't change the backend locking logic at all. Note, the markup backend writes out its database atomically using the tmp-file and rename() approach. That means in that case we'll get roughly "last write wins" which I think is what we want. It's not exactly that I guess, it's more "last sync wins", but that's probably good enough and something we could refine separately. I don't think the multiple gnome logins per user on the same machine problem is super interesting though, because it's something that's never really worked for users that well anyway. We even actively discourage it from gdm, I believe. With this patch /tmp isn't involved at all anymore, so there shouldn't be any issues with malicious users, selinux labeling problems, uid changes, etc. Those types of problems were the main motivation for making the patch. Anyway, I've committed this patch fairly early in the development cycle, and I've already built the patch into packages that will be hitting rawhide as soon as F9 goes out the door, so we should have lots of time to bang out any problems that crop up or revert the patch if it ends up being a fundamentally broken idea.
fair enough ;-)
See bug 558181 for a regression caused by this change.