GNOME Bugzilla – Bug 331689
bad assumptions about /var/run/console ?
Last modified: 2006-03-07 20:32:21 UTC
Running 1.5.13 on Gentoo. The whole automounting business isn't working, and it looks like this part of the code (main() in manager.c) is the cause: if (gvm_get_clipboard () && gvm_user_at_console ()) { gnome_client_set_restart_style (client, GNOME_RESTART_ANYWAY); } else { gnome_client_set_restart_style (client, GNOME_RESTART_NEVER); if (gvm_user_at_console ()) warn ("already running"); return 1; } The effect of this logic is: if we can't get the clipboard _or_ the user is not at a console, then bail out. Is this correct? My system doesn't have the whole /var/run/console structure. Is that a pam-ism? I don't run pam. For this reason, gvm_user_at_console() always returns FALSE so g-v-m bails out at that point.
Created attachment 59654 [details] [review] patch I don't really understand why the user_at_console() check is run at this point. This patch changes the logic to: if we fail to get the clipboard, bail out (with a message if a user is at the console). Does that make sense? I have commit access if this is acceptable.
/var/run/console does not only depend on PAM, it depends on the pam_console module which isn't upstream yet (why?). So it'd probably be wise to make it possible to disable the console check with a configure option.
Or how about at runtime, based on the presence of the /var/run/console directory itself? user_at_console() could be set to always return TRUE when it does not exist.
Created attachment 59844 [details] [review] Detect pam_console at runtime Something like this?
There are a couple of solutions which create a /var/*/console/<user> file when a user is logged in at the console. Just like the D-BUS configure option, g-v-m has the same ./configure --with-console-auth-dir command-line switch which you need to use if your system doesn't use /var/run/console/ (which is provided as the default).
My system doesn't appear to have such a solution in place. Is there a possibility that g-v-m could support such a configuration (i.e. with the above patch), or is the user_at_console() functionality considered too important to disable on systems like mine?
the problem it's trying to address is as such: if the machine is multi-user and there are multiple remote users logged in and a user at the console... when the user at the physical console sticks in a cdrom or a usb thumb drive, there's a race condition as to which g-v-m instance will mount it. Clearly the one that *should* mount it is the one running on the console (because it belongs to the user that has physical access to the machine). So the code is meant to prevent g-v-m from even running when not at the console (no point wasting cpu cycles if we aren't gonna be doing anything, right?) I suppose I could add a configure check (or switch) to see if we should even bother caring in the single-user setup (I presume you fit this category?) and let that check slide with a #ifdef or something? (or I suppose that if the dirname doesn't exist, we could just ignore the check without the need of a #ifdef) What does DBus do?
Thanks for the explanation. I looked at dbus, in terms of detecting user presence it does exactly the same as what g-v-m currently does. I don't really know much about dbus internals so I'm not sure what it uses that information for, but it seems to be used to build up sets of rules to be used as some kind of policy..? dbus seems to function OK even though it thinks I am never a console user. Yes, I fit in the strictly single-user category. As for working around the issue in g-v-m, the runtime check makes most sense to me. I think if /var/run/console does exist then we can safely pam_console is in use? That way packagers don't have to worry about another configure switch, and g-v-m can automatically adapt to whatever situation. See the patch I posted in comment #4.
*** Bug 333044 has been marked as a duplicate of this bug. ***
fixed in CVS by adding a configure time flag