GNOME Bugzilla – Bug 324159
Doesn't work well with two+ users on the same machine
Last modified: 2007-12-07 03:28:29 UTC
Please describe the problem: The user(s) on DISPLAY != :0 can't use removable media properly. Steps to reproduce: 1. Login as user1 on DISPLAY :0 2. Login as user2 on DISPLAY :1 3. g-v-m for user2 doesn't start, saying: "** (gnome-volume-manager:1094): WARNING **: manager.c/2596: not on the system console" 4. if user2 inserts a DVD/CD/etc. or plugs in a camera/device/etc., *user1*'s g-v-m mounts it 5. The mounted device has *user1* permissions, and user2 can't umount/eject it Actual results: Expected results: g-v-m should not mount devices when another X session is active and currently used Does this happen every time? Other information:
this is not an easy problem to solve, there's no way to tell which of the 2 is "active"
Wouldn't it be simpler if the default settings for the mounted devices were +w for a generic "removable" group, with all the relevant users in the group? I don't actually know if this would enable all the users to unmount it, though.
*** Bug 324557 has been marked as a duplicate of this bug. ***
apparently dbus has some way of telling what user is active, so I'll take a look at how they do it one of these days... hopefully they have some function I can call to get that rather than having to copy the code.
ok, apparently not... dbus just has a way of telling if the user is logged in at the console but that doesn't help us solve this problem.
Uhm... the Fast User Switcher Applet (FUSA) seems to know what user is "current" on the X server. http://ignore-your.tv/fusa/ Could this help?
FUSA does its trick with GDM's help and g-v-m could do it as well with a combination of CONSOLE_SERVERS and QUERY_VT commands after connecting to the X display. http://www.jirka.org/gdm-documentation/x1180.html BTW, IMO implementing this mechanism/information someway in dbus, would be cleaner.
proposal by DavidZ can be found at http://blog.fubar.dk/?p=63
*** Bug 327439 has been marked as a duplicate of this bug. ***
Created attachment 58212 [details] [review] Make gvm skip events when it doesn't belong to current VT
A while back I created a patch against 1.2.0 that fixes this. I've send it to the debian BTS (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=305846) and to the utopia list, but it didn't get that much attention. I'll attach it here, it's easily ported to the current version. It's really quite simple, actually and you don't need GDM or whatever. You can just query the console what the current virtual terminal is with ioctl(fd, VT_GETSTATE, &vtstat) vtstat.v_active then just contains the current active VT. You just need <sys/ioctl.h> and <linux/vt.h>. OK, it would be nicer for non-linux platforms to abstract it out a bit, but do they have virtual terminals anyway? Also the proposal in DavidZ's blog seems a bit to complicated for what we try to achieve here.
doesn't compile on my system, I don't seem to have a libconsole nor lct/console.h
I should also point out that you can't assume /dev/tty%d
it turns out your code just wouldn't work anyway since my uid doesn't own the vt device that my X display is running on, so even if I did have the necessary deps, your function would always return FALSE for me.
OK, my hack is a bit debian-specific. We can find the active virtual terminal, that's not the problem. Now we need a way to find out what virtual terminal g-v-m is running on. Finding the display string is easy, but I don't know a clean way to map that to the VT.
Somebody on the xorg list proposed looking in X's log. If the platform (linux,..) allows for virtual terminals it will log there on which one it starts. There's also a function to ask a Display the path to it's log. Do you think that would make an acceptable implementation?
I think I'd rather use DavidZ's dbus idea
How about a completely different approach? As far as I know (I may easily be wrong, though), when you switch away from an X server, all windows get an Xlib event that their full window is obscured now, and when you switch back, they get an event that they are exposed and should be redrawn. Could gvm probably create a toplevel unmanaged transparent 1x1 pixel window and then ask the X server whether that window is visible or obscured? Or isn't there maybe a straighforward extension for querying this in the newest XFree/X.Org releases?
(In reply to comment #11) > It's really quite simple, actually and you don't need GDM or whatever. You can > just query the console what the current virtual terminal is with > ioctl(fd, VT_GETSTATE, &vtstat) Unfortunately it's not that simple either. In order to do this, you need to open a fd that refers to a console. libconsole tries to open /dev/tty, /dev/tty0 and /dev/console for this purpose. /dev/tty is the controlling terminal of the process, normally with 666 perms, but most like it is not a console. /dev/tty0 and /dev/console are console devices, but are normally not accessible to regular users. So there is a permission problem for non-root people. Maybe we need a setuid helper binary that is only launchable by g-v-m and tells the vt number.
Created attachment 64045 [details] [review] a works-for-us case study patch I attach a patch that I've just committed into the UHU-Linux distribution. It is only a proof of concept, or case study (call it whatever you want), clearly very far from being suitable for mainstream commit. It may contain ideas, however. Here's what it does: A setuid helper answers (via its exit status) whether it's true that the vt given as command line argument is the foreground one. For privacy reasons it is only willing to check this if the invoking program is /usr/bin/gnome-volume-manager. I do hope that this setuid bit does not bring any security or privacy (information leak) risk. Since it is accessing the /proc filesystem, it is quite Linux-specific. At startup, g-v-m checks whether the DISPLAY variable refers to a local display, and if it is the case, reads the vt number from the /var/log/Xorg.<N>.log file. Yet again it assumes a lot of things: this file exists (hence Xorg is running and this is the name of the log file), this file is readable by normal users, and the wording for the vt number is the same as on my machine with X.Org 7.0. If all this went okay and we have the vt number, then each time some action should be performed by g-v-m, it calls the setuid helper to see whether the display it is running at is visible. Advangates: - not using gdm, hence it also works with any other dm, startx, manual vt switching and so on - does not require special libraries installed - anyway, it is working for me :) Disadvantages: - a lot discussed above - not autoconf/automake-ized, contains hard-coded paths PS: my colleague suggested not to bother with XOrg's log file, only check if the current vt is the same at g-v-m's startup and when something needs to be performed. It would be simpler and less hackish to implement it, but the result would be more buggy for experienced users (since the display may not be active when g-v-m starts up).
A note to the original report: It is not only mounting that should only be performed for the active user. For example if you insert a movie DVD, gmplayer starts playing this DVD for both users. Hence it becomes much slower; depending on the sound system either only one of them plays sound (so the user may seek in the movie and wonder why the audio keeps playing without seeking), or both play it with a small time offset; and so on, there are a lot of troubles...
So far the discussion covers only simple setups with one "active" user. Please don't forget about multi-seat machines with multiple users logged in.
Created attachment 89770 [details] [review] (GIMP patch attached here by mistake)
The way to solve this is to use PolicyKit and/or whatever that daemon is that can tell you the active user on a console (which I think is part of PolicyKit but not sure)
http://www.freedesktop.org/wiki/Software/ConsoleKit
fixed in svn