GNOME Bugzilla – Bug 609321
gdm monitors for $HOME/.face even when IncludeAll is false
Last modified: 2010-07-02 19:03:21 UTC
(forwarding my own bug report from https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/518810) I'm using kerberized NFS mounts, and the gdm user has no business poking them. Still I get a lot of log spam because gdm can't get a krb5 context. The reason for this is that it adds a monitor for $HOME/.face, but can't get to it: Feb 8 14:48:46 nexus6 gdm-simple-greeter[5349]: DEBUG(+): adding monitor for '/u/00/tjaalton/unix/.face' Feb 8 14:48:46 nexus6 rpc.gssd[3602]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Feb 8 14:48:46 nexus6 rpc.gssd[3602]: handle_gssd_upcall: 'mech=krb5 uid=113 ' Feb 8 14:48:46 nexus6 rpc.gssd[3602]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt0) Feb 8 14:48:46 nexus6 rpc.gssd[3602]: process_krb5_upcall: service is '<null>' Feb 8 14:48:46 nexus6 rpc.gssd[3602]: getting credentials for client with uid 113 for server foo.hut.fi Feb 8 14:48:46 nexus6 rpc.gssd[3602]: CC file '/tmp/krb5cc_0' being considered, with preferred realm 'REALM' Feb 8 14:48:46 nexus6 rpc.gssd[3602]: CC file '/tmp/krb5cc_0' owned by 0, not 113 Feb 8 14:48:46 nexus6 rpc.gssd[3602]: WARNING: Failed to create krb5 context for user with uid 113 for server foo.hut.fi Feb 8 14:48:46 nexus6 rpc.gssd[3602]: doing error downcall I don't think it should do that when IncludeAll is false, ie. it shouldn't list previous users at all in that case (note that it doesn't help even if I remove /var/cache/gdm/ contents..).
Created attachment 153857 [details] [review] patch fixing problem This patch ensures that the monitor for .face is not added if include_all is false. It would be useful if the bug submitter could build with this patch and test to let us know if this resolves the problem. However, I wonder if this should be managed by a separate GConf key. Whether or not GDM touches the user's $HOME directory before authentication is only an issue for environments like kerberos. Setting include_all to false just means that the user wants only those users who have logged in before to show up in the face browser instead of all local users. Some users who set include_all to false may want the icon to refresh if they aren't using something like kerberos. However, looking at the code, I notice that the monitor does not actually do anything. It emits a signal, but the on_user_icon_changed function in gui/simple-greeter/gdm-user-manager.c just prints out a debug statement and doesn't actually update the icon. Perhaps it would make the most sense to just remove the monitor completely for now and reconsider this issue when someone wants to actually make the icon refresh do something when the icon changes. Thoughts?
Note, that if you run GDM with the face browser turned off, that this should avoid all calls that make GDM touch the user's $HOME directory before authentication. So, this problem should only exist when the face browser is being used.
Fixed in master. I ripped out the non-functional monitor so this file isn't being watched anymore. If there is a desire to add back code to make GDM monitor these files it should be implemented properly in a way that doesn't cause the problem reported in this bug report.
*** Bug 607728 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > However, I wonder if this should be managed by a separate GConf key. Probably, or automatically turn the entire user picture thing off if you have more than just a few users. > Whether > or not GDM touches the user's $HOME directory before authentication is only an > issue for environments like kerberos. No! This is a problem on ANY installation with more than just a few users and home directories on file servers! Please note that people are trying to use this code on systems with 10.000's or 100.000's of users. In fact, there are several bugs in this area that shows that it can never has been tested in a larger environment. For example, if the inotify_add_watch fails, for example because the process has reached its limit, it will loop and try to add them again, for ever it seems. Having a bunch of machines hitting every user's home directory in sequence over and over as fast as it can be a problem for many network file systems. Again, please note that people are trying to deploy this code in large installations, and please think the design, features and tests through for this use.