GNOME Bugzilla – Bug 603240
Metacity shows gvim as running in superuser mode even if not
Last modified: 2014-06-04 08:25:44 UTC
This bug has been reported downstream in Gentoo and Debian: https://bugs.gentoo.org/show_bug.cgi?id=292517 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=549290 When gvim is launched without the -f ("foreground") option within metacity-2.28.0 (e.g. by running it from gnome-terminal), the window titlebar shows "[No Name] GVIM (as superuser)"
A little tinkering with xprop shows that when I run gvim without "-f", the resulting window has the "_NET_WM_PID" set to a PID that doesn't actually exist: $ xprop | grep PID _NET_WM_PID(CARDINAL) = 20669 $ ls /proc/20669 ls: /proc/20669: No such file or directory Apparently this functionality was added to Metacity in this commit: http://git.gnome.org/browse/metacity/commit/?id=ab6aa5463ffdd5cfaf729eb1f5407be749ba1090 ...but I don't see any error-handling for the case where owner_of_process() is handed a bogus PID. Indeed, gtoplib doesn't seem to have much in the way of error-handling at all: http://library.gnome.org/devel/libgtop/stable/libgtop-procuid.html#glibtop-get-proc-uid At a high level, obviously Metacity should be sanity-checking _NET_WM_PID before using it, but exactly how that could be achieved, I don't know.
Created attachment 153908 [details] [review] Add error handling to glibtop_get_proc_uid Hi I believe this patch fixes this bug. It adds error handling for the glibtop_get_proc_uid() call. Apparently glibtop functions report which fields contain valid data via the "flags" field.
Yes, above patch fixes this bug :-D Thanks a lot!
But it doesn't completely solve the problem is, after applying it, gvim is never shown as run by superuser even when it's really being run as root (while metacity works fine with gedit, for example) :-/
> But it doesn't completely solve the problem is, after applying it, gvim is > never shown as run by superuser even when it's really being run as root (while > metacity works fine with gedit, for example) :-/ I guess that is now technically a bug in libgtop, not metacity.
Is there any chance this might get looked into? The bug is still present in Metacity 2.30 and my patch still applies.
It seems the upstream developers have little interest in metacity now. Fortunately, this problem doesn't exist in mutter. So we can just wait and celebrate for the death of metacity and then completely switch into mutter in future ...
(In reply to comment #7) > It seems the upstream developers have little interest in metacity now. > Fortunately, this problem doesn't exist in mutter. So we can just wait and > celebrate for the death of metacity and then completely switch into mutter in > future ... That is unfortunate. mutter seems to bring all of my machines to their knees (Core 2 Duo 2.2 GHz, w/ GMA4500, Core 2 Duo w/ nvidia quadro), neither of which are really old.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.