GNOME Bugzilla – Bug 162849
gdmcomm doesn't support process hiding
Last modified: 2010-06-04 19:43:04 UTC
During gdmflexiserver startup, gdmcomm_check() checks whether gdm is working by doing kill(pid,0) to gdm process. This is unnecessary and will fail if system is hiding processes of other users, for example in FreeBSD5.3 it happens when security.bsd.see_other_uids sysctl is set to 0. I think that users of systems like grsecurity under Linux with process hiding enabled will have the same problem.
I would accept a patch that replaced this test with a different test that works with process hiding.
I think there are more serious issues here with the way slaves are trying to find out if the deamon is available for communication. A few releases ago, GDM was modified so that configuration data is passed over the communication pipe. This is an improvement since it means only the daemon has to know how to read the configuration file, and makes it possible for GDM to support default-system/per-system-configuration/per-display configuration. However, gdmcomm_check does this: pidfile = gdm_config_get_string (GDM_KEY_PID_FILE); to get the PID file to check to see if GDM is available. This is pointless since accessing configuration data before checking the connection (or if the daemon is running) causes the client to use the communication socket to get the data. So if the daemon isn't running (or if you move /tmp/.gdm_socket aside for testing), then you see that GDM will fail to connect to the server 5 times (sleeping 1 second per try). Then it will use the compiled in value (and if the user hasn't changed their PidFile configuration value), then it will check the process and pop-up the dialog. Gross. We should fix gdmcomm_check so that it doesn't access configuration data and make sure it is always called *before* reading in configuration data (all clients do this in bulk - the call gdmcomm_comm_bulk_start should be called before reading the first configuration value. This is broken since gdmcomm_check accesses one config value before the bulk_start call. This means we open the socket connection twice for each client, which slows things down. How do we fix this? One idea would be to deprecate the PidFile configuration option so that the clients always know where the PidFile is located (default /var/run/gdm.pid). In other words, make the daemon always return a static value if the user calls GET_CONFIG on this key and ignore the setting in the configuration file. This way the clients could know where the file is located. Or perhaps we could set an environment variable for the clients to use, but this would break if the user modified their environment (or did su - or something). Or we could create another file in /tmp pointing to the actual location of the PidFile. We should do something like this and fix gdmcomm_check so it doesn't access configuration to find out the location of this file. While we're doing this, we should create a new configuration key so the user can specify to not do the kill() test. Perhaps a key like "UsingProcessHiding" which if true will just avoid the kill () test, so that GDM can be used when process hiding is enabled.
*** Bug 340610 has been marked as a duplicate of this bug. ***
2007-03-26 William Jon McCann <mccann@jhu.edu> * config/gdm.conf.in: * configure.ac: * daemon/gdm-daemon-config-entries.h: * daemon/gdm-daemon-config-keys.h: * daemon/gdm-daemon-config.c: (gdm_daemon_config_to_string), (check_servauthdir), (handle_no_displays), (gdm_daemon_change_user), (gdm_daemon_check_permissions): * daemon/gdm.c: (gdm_daemonify), (gdm_final_cleanup), (main): * gui/gdmXnestchooser.c: (main): * gui/gdmcomm.c: (gdmcomm_check): * gui/gdmlogin.c: (gdm_read_config): * gui/greeter/greeter.c: (gdm_read_config): Remove the PidFile configuration option. Fixes #162849
William - Thanks for fixing the PID issue, but we also need to make a configuration option to avoid the kill() test. Reopening bug and fixing synopsis. If you want to fix this, adding a new config option for this is probably not much work.
Also William, the PID fix should probably go back into the 2.18 branch, since it would be nice if this were fixed in the next stable release. Any chance you might be able to backport this?
Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.