GNOME Bugzilla – Bug 565151
Thrashing autofs home directory mounts
Last modified: 2010-07-02 19:11:48 UTC
Please describe the problem: Description of problem: This issue showed up in Fedora 9. I thought it would be fixed before Fedora 10. If a user has ever logged into a system it is remembered across reboots. Then some process, gdm-simple-greeter, is using that information to probe the users home directory which causes autofs to mount the home directory. This issue was reported 5 months ago at bugzilla.redhat.com, 456021. Really need to get this fixed. Steps to reproduce: 1. 2. 3. Actual results: NFS server system /var/log/messages file: Dec 16 07:42:58 douglas mountd[2526]: authenticated mount request from redwood.highley-recommended.com:702 for /export/home/dhighley (/export/home) Dec 16 07:49:13 douglas mountd[2526]: authenticated unmount request from redwood.highley-recommended.com:962 for /export/home/dhighley (/export/home) Dec 16 07:49:14 douglas mountd[2526]: authenticated mount request from redwood.highley-recommended.com:785 for /export/home/dhighley (/export/home) Dec 16 07:55:28 douglas mountd[2526]: authenticated unmount request from redwood.highley-recommended.com:709 for /export/home/dhighley (/export/home) Dec 16 07:55:30 douglas mountd[2526]: authenticated mount request from redwood.highley-recommended.com:934 for /export/home/dhighley (/export/home) Expected results: Do not access users home directories if they are not logged in. Does this happen every time? Other information: Turning on debug revealed: Dec 16 20:03:20 redwood automount[8393]: expired /home/dhighley Dec 16 20:03:20 redwood automount[8393]: send_ready: token = 827 Dec 16 20:03:20 redwood automount[8393]: expire_cleanup: got thid 14041932134638 4 path /home stat 0 Dec 16 20:03:20 redwood automount[8393]: expire_cleanup: sigchld: exp 1404193213 46384 finished, switching from 2 to 1 Dec 16 20:03:20 redwood automount[8393]: st_ready: st_ready(): state = 2 path /h ome Dec 16 20:03:22 redwood automount[8393]: handle_packet: type = 3 Dec 16 20:03:22 redwood automount[8393]: handle_packet_missing_indirect: token 8 28, name dhighley, request pid 17193 Dec 16 20:03:22 redwood automount[8393]: attempting to mount entry /home/dhighle y Doing a ps -efl | grep 17193 led to /usr/libexec/gdm-simple-greeter. Removing execution permission and killing the process confirmed that automounter was no longer being asked to mount the home directory. So now how do we get control of gdm-simple-greeter so that it is not accessing automounted home directories? We see this is a duplicate bug now that the issue is understood.
I think you can take this out of the unconfirmed state as it has been reported a long time ago: https://bugzilla.redhat.com/show_bug.cgi?id=456021 2008-07-20 17:25 EDT by Vegard Lima
I can confirm that killing gdm-simple-greeter and preventing it from starting again (temporary removing x-bit from the binary - gdm is still running) solves the repeading umount / mount problem of automounted /home/* directories. I think the best would be a gconf key to activate the search of files in users home directories if they are on nfs partitions - with the default being off. And gdm should test once if a home directory is on nfs and cache the state during a running instance of gdm, and forget it on a reload and restart. I am using autofs-5.0.3-36.x86_64 on Fedora 10.
Note that accessing automounted directories before authenticating can cause problems in some environments. Note bug #155077 for an example. I agree that a configuration option to enable/disable accessing the user's $HOME directory before authentication is probably a good idea. Not sure if the default should be on or off, though.
we should just stop storing stuff in the user's home directory. The only things we need access to right now are ~/.dmrc and the face image. we should cache them locally in /var.
What's it take to get a bug acted on? I find it hard to believe that this still has a status of unconfirmed.
You could try raising the issue on the gdm-list@gnome.org forum. It sometimes helps to engage the experts on the list. Also, if someone could put together a patch, or a more complete proposal of how this should work; then that would likely speed things. Moving the file location to where, specifically, under /var? Would it be stored per-user? Would the username be a part of the filename, or would data be stored in a single file, perhaps in INI format, and read via gkeyfile?
Ok, I will try the email list. Gnome is large or I would look for the problem and put in a fix if it were accepted.
Created attachment 142293 [details] [review] patch to access dmrc and file files from /var/cache/gdm This patch causes GDM to store the dmrc and face image files in /var/cache/gdm/(user). The files are copied to this directory immediately after the .dmrc file is written to the user's $HOME directory as the user session starts and again at logout. This ensures that any changes to the files are copied to the cache for next login. This does mean that on first-time login, the user's dmrc and face image will be ignored, since the files are only copied to the cache after pam_setcred. But this is normally okay since most users won't have files the first time they login. Can this go upstream?
Comment on attachment 142293 [details] [review] patch to access dmrc and file files from /var/cache/gdm what's the point of the relax group stuff? If it's always TRUE, why have the arguments? calling "cp" is a non-starter, you should use gvfs to do the copy.
s/gvfs/gio/
Created attachment 142840 [details] [review] updated patch Here is an updated patch. Actually, on further review, I noticed that there were some bugs in my previous patch. This patch fixes the following issues: 1) Now uses g_file_copy instead of calling cp. 2) Since /var/cache/gdm is not user-writable, we need to write the $HOME/.dmrc file before we setuid as the user. So I moved the call to _save_user_settings before the setuid call and the gdm_session_settings_save now chowns the file to the user's user/group after creating it, then it is copied to the cache. 3) The return code fromt he gdm_cache_copy_file wasn't being passed up properly so it wouldn't try the alternative face files. That's now fixed. 4) Some general cleanup of the patch. For example, the code now uses worker->priv->uid rather than looking up the uid again. Also cleaned up the check_user_file as you suggest.
Created attachment 142949 [details] [review] updated patch Here is an updated patch based on discussion with Ray on IRC. Changes include: 1) Now the /var/cache/gdm directory is owned by root:gdm with 755 permissions instead of 700 permissions. 2) The /var/cache/gdm/username directory is now owned by the user with 755 permissions instead of being owned by root:gdm. 3) The files in /var/cache/gdm are owned by the user with 644 permissions. 4) When starting the session, gdm-session-worker.c now makes sure to create the cachedir before dropping to user permissions, but actually copies the files to the cachedir as the user. 5) I added some debug to simple-greeter/gdm-user.c 6) I cleaned up the patch quite a bit so it is now nicer.
(In reply to comment #12) Thanks for working on a patch! I am not sure if the directory /var/cache/gdm/username may contain sensitive personal information. But a general security design goal is to grant only the rights that are neccessary. Question: Is read permission for others neccessary? If it is not, then I suggest to set the permission to 0750 (directory) and 640 (files) and set the group to gdm. Then gdm will be able to read it but other users cannot read it.
The information isn't really sensitive. The cache contains two files. - The dmrc file just specifies the user's default session and language selections. - The face image, which is visible to all users in the Face Browser on the login GUI anyway.
Comment on attachment 142949 [details] [review] updated patch let's get this in.
Thanks, pushed to master.