X-windows programs don't work anymore for root. And whatever is making these messages sure doesn't give a clue as to what package to reassign the bug to. # emacs -Q #sometimes things work, (but only for a few minutes.) But mostly they don't start at all anymore: # emacs -Q g_dbus_connection_real_closed: Remote peer vanished with error: Underlying GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting. # firefox ** GLib-GIO:ERROR:/build/buildd-glib2.0_2.28.6-1-i386-A3fp41/glib2.0-2.28.6/./gio/gdbusconnection.c:2279:initable_init: assertion failed: (connection->initialization_error == NULL) Aborted
jidanni@jidanni.org writes: These both sound like dbus misconfiguration to me. Does something as simple as "xclock" work?
TJL> These both sound like dbus misconfiguration to me. Does something as TJL> simple as "xclock" work? Yes xclock works.
jidanni@jidanni.org writes: Ok. You really need to describe what sort of setup you are using before it is possible to guess what could be wrong. Are you starting dbus session bus at all?
TJL> jidanni@jidanni.org writes:
TJL> it is possible to guess what could be wrong. Are you starting dbus
TJL> session bus at all?
I think so. I see its name here:
# pstree -A
init-+-acpid
|-atd
|-bash---xterm---su---bash---pstree
|-console-kit-dae---64*[{console-kit-da}]
|-cron
|-2*[dbus-daemon]
|-dbus-launch
|-dictd
|-exim4
|-getmail---sleep
|-getty
|-login---bash
|-nodm---strace---nodm.real-+-Xorg
| `-nodm.real---ck-launch-sessi-+-bash---icewm-session-+-icewm
| | |-icewmbg
| | `-icewmtray
| `-ssh-agent
|-ntpd
|-pdnsd---3*[{pdnsd}]
|-pppd
|-rsyslogd---3*[{rsyslogd}]
|-scim-helper-man
|-scim-launcher
|-scim-panel-gtk---{scim-panel-gtk}
|-smartd
|-udevd---2*[udevd]
|-wwwoffled
|-xterm---bash---emacs-+-aspell
| `-2*[{emacs}]
`-z50apt-get---sleep
This bug started happening this month. And on all my computers.
jidanni@jidanni.org writes: This is probably your dbus system bus. It's hard to say since pstree does not show what arguments were used.
TJL> This is probably your dbus system bus. It's hard to say since pstree TJL> does not show what arguments were used. # pstree -aA|grep dbus | |-grep dbus |-dbus-daemon --system |-dbus-daemon --fork --print-pid 5 --print-address 7 --session |-dbus-launch --sh-syntax --exit-with-session
reassign 633652 dbus thanks I'll leave it to the dbus maintainer to either close this bug or do $whatever ;-) Thanks & cheers! to But mostly Underlying 0). A3fp41/glib2.0-2.28.6/./
We believe that the bug you reported is fixed in the latest version of
dbus, which is due to be installed in the Debian FTP archive:
dbus-1-dbg_1.4.12-5_amd64.deb
to main/d/dbus/dbus-1-dbg_1.4.12-5_amd64.deb
dbus-1-doc_1.4.12-5_all.deb
to main/d/dbus/dbus-1-doc_1.4.12-5_all.deb
dbus-x11_1.4.12-5_amd64.deb
to main/d/dbus/dbus-x11_1.4.12-5_amd64.deb
dbus_1.4.12-5.debian.tar.gz
to main/d/dbus/dbus_1.4.12-5.debian.tar.gz
dbus_1.4.12-5.dsc
to main/d/dbus/dbus_1.4.12-5.dsc
dbus_1.4.12-5_amd64.deb
to main/d/dbus/dbus_1.4.12-5_amd64.deb
libdbus-1-3_1.4.12-5_amd64.deb
to main/d/dbus/libdbus-1-3_1.4.12-5_amd64.deb
libdbus-1-dev_1.4.12-5_amd64.deb
to main/d/dbus/libdbus-1-dev_1.4.12-5_amd64.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 633652@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Simon McVittie <smcv@debian.org> (supplier of updated dbus package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
Format: 1.8
Date: Fri, 15 Jul 2011 10:45:56 +0100
Source: dbus
Binary: dbus dbus-x11 libdbus-1-3 dbus-1-doc libdbus-1-dev dbus-1-dbg
Architecture: source amd64 all
Version: 1.4.12-5
Distribution: unstable
Urgency: low
Maintainer: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
Changed-By: Simon McVittie <smcv@debian.org>
Description:
dbus - simple interprocess messaging system (daemon and utilities)
dbus-1-dbg - simple interprocess messaging system (debug symbols)
dbus-1-doc - simple interprocess messaging system (documentation)
dbus-x11 - simple interprocess messaging system (X11 deps)
libdbus-1-3 - simple interprocess messaging system (library)
libdbus-1-dev - simple interprocess messaging system (development headers)
Closes: 633652
Changes:
dbus (1.4.12-5) unstable; urgency=low
.
* Undo the changed invocation for dbus-launch, which seems to cause
more problems than it solves (LP: #807614, LP: #809900, probably also
Closes: #633652)
* Work around #453755 by just reopening stdin from /dev/null instead,
until fd.o #39197 gets fixed
Checksums-Sha1:
3c53aab10e75a667f09f99144fda45953abcbb9e 2219 dbus_1.4.12-5.dsc
a6541b41bca518bd1efce318925f5dfc62b23444 32877 dbus_1.4.12-5.debian.tar.gz
bdc942953027575a9e8373068e09c94ec52fa25d 387488 dbus_1.4.12-5_amd64.deb
eca3b686d2392ce0bf9ff953701b1c881b3ffe7f 52122 dbus-x11_1.4.12-5_amd64.deb
b27ed7c107c64b7abf6922979e50e2ec98aae733 162464 libdbus-1-3_1.4.12-5_amd64.deb
aa20797111e8384fb580da6c64db67e575953173 2086526 dbus-1-doc_1.4.12-5_all.deb
850144e6e6ca8a7f86615017a8a4880a5bb34de0 241532 libdbus-1-dev_1.4.12-5_amd64.deb
d94b4990a8cb0da229efb097b6346910075ff9d2 3593164 dbus-1-dbg_1.4.12-5_amd64.deb
Checksums-Sha256:
d0da32c4ad6a23cc9f7390ebb0f380c35ec09900ee9b276ba84266e23ebff00b 2219 dbus_1.4.12-5.dsc
6a3e2a81bb6916761ef3c6043d222560c729c237876e2da5ebd183bfa6d20435 32877 dbus_1.4.12-5.debian.tar.gz
d88cc6e4db0d9f794bc75a68a0cffb5852862e390d5252f12f30e26247d59ce3 387488 dbus_1.4.12-5_amd64.deb
f840ac41620eadead0e974be55becf5f17c4276872265445ce8c8bd6f1c370b9 52122 dbus-x11_1.4.12-5_amd64.deb
45d250014cdd7ba9fa8dd27144a3511abbe2b80cb915618f775b320a090a013f 162464 libdbus-1-3_1.4.12-5_amd64.deb
6331d52b6cca200fc75b56eb08e806a478f2e8e206d35291c9d6b6b8862b3a51 2086526 dbus-1-doc_1.4.12-5_all.deb
d86009cc5c615c1f510f4f735ea392fd7368ab959942d8d980578c57b36ef0b1 241532 libdbus-1-dev_1.4.12-5_amd64.deb
0b479f77a260592e3c96cebb39a7237efc1c9c4fb3a24722921837b410035caf 3593164 dbus-1-dbg_1.4.12-5_amd64.deb
Files:
a6f0b40b3882b862b6b2aa25fa710d1a 2219 devel optional dbus_1.4.12-5.dsc
1b8d6149d8de176a87a5be6e4fafbac2 32877 devel optional dbus_1.4.12-5.debian.tar.gz
761d4cc6d01348978fca563caef31318 387488 devel optional dbus_1.4.12-5_amd64.deb
81218d57e8193f28aff936a63c7f51ca 52122 x11 optional dbus-x11_1.4.12-5_amd64.deb
45508ed491974fe91c50c920eaa19fd3 162464 libs optional libdbus-1-3_1.4.12-5_amd64.deb
8420604c1485a3c986f7aea47aa381de 2086526 doc optional dbus-1-doc_1.4.12-5_all.deb
d11b0ac1856dedfa0b45c1f0d5b9a374 241532 libdevel optional libdbus-1-dev_1.4.12-5_amd64.deb
e484eefc5d98be4eefd9b19568cf02f4 3593164 debug extra dbus-1-dbg_1.4.12-5_amd64.deb
-----BEGIN PGP SIGNATURE-----
iQIVAwUBTiAUT03o/ypjx8yQAQiUgA/9FGo/PQRZnxN4/d7YyBZv28u90lCmjGx4
L4Q1ui9SdtKerjHZCWbTgRdickkqj4JP47zKaWMbYX0xubudAY9rxKi2nO1Iw/mL
YZQf2AB/pkc7DP7+rP5cFDMw130YCrNJ6YkiZGPdqJ9h3OnIvcnQH9bve6uWgy1b
lLekyZnjMera8GjPqpPk6Esggr3BwNLIyIsinaSJt+npk+yfpHkb+N4cmk8FKddd
+qW4NpogcrbcQeU05bejyhAjMqfMW90tfGglkZBFpqzZUG4c60eGMEoKW2dV0A0F
ipQb+IBQl4vqTzqvP5rMxlRH7q1LPWvGOd7GRzLs+Qpd1RhIaW7KWEfX134yp56a
2Ofx2zW9SkAhQExaFPX5FKoxmMLujKbe6ew95Jkq1o/QYHxcthcVJ8tsgdNX8Jmb
CV3905u36Z8X8JmLtIKkND/jp0iKIi5/zbuFD0mL/QSCvuxWK+a3SpSzsw2xidYa
2ti6bmOJc4WvZVLB7sx9VmUG5Vy9TCr88OPeYMWTVWNucaUSvINmG4mqYgZXA1t0
Vvna39V9LY/08pUw+Qv3Bsj7wj39sQ/HbilOhKZFFULEaE86H6YzGV9GUFEsCRNP
F4b6786fzRmb8ONve4CsaJnNC2nZUmz6smjsorl473mobzHufQGVhb+enVRJowb5
GsiGV/XlbNs=
=dj1t
-----END PGP SIGNATURE-----
In the mail from Simon McVittie <smcv@debian.org>
he states that the bug #633652 is fixed and
closed by the new version of the package
dbus_1.4.12-5_amd64.deb and its friends.
I immediately upgraded both a Debian unstable and a
Debian testing. Both systems got a new version of dbus:
root@sally:/home/bob# dpkg -l | grep dbus
ii dbus 1.4.12-5 simple interprocess
messaging system (daemon and utilities)
ii dbus-x11 1.4.12-5 simple interprocess
messaging system (X11 deps)
ii libdbus-1-3 1.4.12-5 simple interprocess
messaging system (library)
ii libdbus-glib-1-2 0.94-4 simple interprocess
messaging system (GLib-based shared library)
ii libqt4-dbus 4:4.7.3-5 Qt 4 D-Bus module
then I tested from an xterm su-ed to root. I tested with:
xterm, xclock, iceweasel and emacs. The xterm and xclock
worked but both iceweasel and emacs failed with the same
error as reported originally by jidanni@jidanni.org:
GLib-GIO:ERROR:/tmp/buildd/glib2.0-2.28.6/./gio/gdbusconnection.c:
2279:initable_init: assertion failed:
(connection->initialization_error == NULL)
Fatal error (6)Aborted
reopen 633652
retitle 633652 Gtk applications (emacs, iceweasel) no longer start under su to root
thanks
I'd thought that this was additional fallout from working around the most
important case of #453755 (which did cause some regressions), but apparently
not.
I notice that both Iceweasel and Emacs use Gtk, so the cause of the assertion
error is probably a behaviour change in either Gtk or GLib causing it to
connect to D-Bus where it previously didn't.
In the emacs case reported by jidanni:
something in the dependency stack is detecting inability to connect to D-Bus
and deciding that it can't go on without D-Bus support. For random X apps this
may be true, for emacs it probably isn't!
In the Iceweasel case reported by Bob and jidanni:
this should never happen: assertions are always a bug. The application or
library (whichever layer is connecting to D-Bus) should catch the error and
deal with it gracefully, either by refusing to run (if D-Bus is an essential
part of its functionality) or by continuing without D-Bus support.
The underlying error can be seen by running dbus-send under su:
[...]
What's happening here is that the DBUS_SESSION_BUS_ADDRESS environment
variable points to your non-root user's session bus, to which other users (even
root) are not allowed to connect. If you unset that environment variable,
the autolaunch mechanism will give you a new session bus ("a new GUI session")
for the combination of user root and the X server you're connected to:
(notice that this mini-session does not contain any of the session services
you'd see in your main GUI session, like org.gnome.GConf or whatever - it
has just started, to accomodate that dbus-send call, and is empty).
If you use something like sudo which unsets most environment variables,
that'd also work.
The long-term solution for this is probably to stop running X applications as
root: in particular, running Iceweasel (huge, network-facing and
security-sensitive) as root sounds like a bad idea. See
<http://www.gtk.org/setuid.html> for Gtk upstream's view of this.
Regards,
S
reopen 633652
retitle 633652 Gtk applications (emacs, iceweasel) no longer start under su to root
thanks
I'd thought that this was additional fallout from working around the most
important case of #453755 (which did cause some regressions), but apparently
not.
I notice that both Iceweasel and Emacs use Gtk, so the cause of the assertion
error is probably a behaviour change in either Gtk or GLib causing it to
connect to D-Bus where it previously didn't.
In the emacs case reported by jidanni:
something in the dependency stack is detecting inability to connect to D-Bus
and deciding that it can't go on without D-Bus support. For random X apps this
may be true, for emacs it probably isn't!
In the Iceweasel case reported by Bob and jidanni:
this should never happen: assertions are always a bug. The application or
library (whichever layer is connecting to D-Bus) should catch the error and
deal with it gracefully, either by refusing to run (if D-Bus is an essential
part of its functionality) or by continuing without D-Bus support.
The underlying error can be seen by running dbus-send under su:
[...]
What's happening here is that the DBUS_SESSION_BUS_ADDRESS environment
variable points to your non-root user's session bus, to which other users (even
root) are not allowed to connect. If you unset that environment variable,
the autolaunch mechanism will give you a new session bus ("a new GUI session")
for the combination of user root and the X server you're connected to:
(notice that this mini-session does not contain any of the session services
you'd see in your main GUI session, like org.gnome.GConf or whatever - it
has just started, to accomodate that dbus-send call, and is empty).
If you use something like sudo which unsets most environment variables,
that'd also work.
The long-term solution for this is probably to stop running X applications as
root: in particular, running Iceweasel (huge, network-facing and
security-sensitive) as root sounds like a bad idea. See
<http://www.gtk.org/setuid.html> for Gtk upstream's view of this.
Regards,
S
clone 633652 -1
reassign -1 libglib2.0-0
retitle -1 GDBus aborts on repeated failure to authenticate with bus daemon
found -1 2.28.6-1
forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=635694
tags -1 + patch
thanks
This part of the bug report seems to be
<https://bugzilla.gnome.org/show_bug.cgi?id=635694> which is a bug in GIO,
fixed upstream in commits 3ea204c and 68b16deb (before versions 2.28.7 and
2.29.4 respectively).
S
clone 633652 -1
reassign -1 libglib2.0-0
retitle -1 GDBus aborts on repeated failure to authenticate with bus daemon
found -1 2.28.6-1
forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=635694
tags -1 + patch
thanks
This part of the bug report seems to be
<https://bugzilla.gnome.org/show_bug.cgi?id=635694> which is a bug in GIO,
fixed upstream in commits 3ea204c and 68b16deb (before versions 2.28.7 and
2.29.4 respectively).
S
SM> The long-term solution for this is probably to stop running X applications as root Root not allowed to use emacs? I'm telling my mom. And I recall synaptic and some other tools are exclusively for root.
Is #633652 also the cause of bug #634699, in a non-root application? All I know is I cannot paste into pcmanx today. Downgrading pcmanx did not help.
retitle 634699 unicode pasting should not cause the whole paste to disappear thanks I see. It is because I tried to paste the line "歡迎到台灣跨性別 Flickr® 社群！" Which contained the deadly (to the big5 world) "®" character, causing the whole input to disappear. It should fail more gracefully!
found 633652 1.5.6-1 severity 633652 grave thanks I'm raising the severity of this bug. I feel it is inappropriate for any more heel dragging to take place. It is embarrassment enough that root is no longer to use X programs on Debian, including system management tools specifically designed for root to use. If one does the following, the whole X session becomes locked. The users half edited letters etc. are taken for ransom. # su - nobody No directory, logging in with HOME=/ nobody@jidanni2:/$ env SHELL=/bin/sh TERM=xterm USER=nobody MAIL=/var/mail/nobody PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games PWD=/ SHLVL=1 HOME=/ LOGNAME=nobody DISPLAY=:0 XAUTHORITY=/home/jidanni/.Xauthority _=/usr/bin/env nobody@jidanni2:/$ emacs /tmp/ee.txt Only an expert user who knows CTRL ALT F1 and pstree etc. will be able to kill the emacs and recover his X session. pstree -aAl shows |-bash /home/jidanni/.xsession | `-xterm -class UXTerm -title uxterm -u8 -bg hotpink4 -title # -name # -e su | `-su | `-bash | `-su - nobody | `-sh | `-emacs /tmp/ee.txt | `-dbus-launch --autolaunch=583e5eeffd5b64952b92010045b373b0 --binary-syntax --close-stderr
r> Hi all: r> I'm a "normal" GUI computer user, I've used things like Delphi, r> Eclipse, gedit, Notepad++ and Visual Studio all my life. I've also r> been using emacs for some time under Ubuntu and under Windows. It r> took me a while to set it up with "standard" behaviour, like r> shift+arrows for text selection and so on, I found the cua mode to be r> helpful. Every now and then, I even click on the menus with the r> mouse. However, I've written some simple, copy-paste lisp too, so I'm r> not just a standard mouse user. In fact, my .emacs file has grown r> much more than I ever thought it would. 8-) r> Now I have to work on a remote server via SSH, and the connection is r> not fast enough to tunnel X Windows over it, so I have to switch to r> console mode with "emacs -nw". r> The console mode has been a shock. There is no mouse at all. I cannot r> navigate the menus as usual, menu-bar-open is weird and unfriendly. r> But, worst of all, some key combinations do not work well. Same for me, but that's life here on Debian, even on ones very own laptop, no SSH involved, and even if you are root, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633652
r> The console mode has been a shock. There is no mouse at all. I cannot r> navigate the menus as usual, menu-bar-open is weird and unfriendly. r> But, worst of all, some key combinations do not work well. But that's the way it must be here on Debian, if you are root. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633652 My question is how do all those high powered Debian Developers cope? Don't tell me they don't use emacs. Or not as root. Not even when administering their system?
I use emacs under X to administer my Debian systems. I don't run it as root though. I use emacs TRAMP to use sudo to edit files as root on the local machine. On remote machines I do the same but in an ssh session in xterm (I don't use mouse or menu bars in emacs in X anyway). Looking at bug 633652, have you tried running X programs as root with sux or gksu instead of su? http://packages.debian.org/squeeze/sux http://packages.debian.org/squeeze/gksu
KR> I use emacs under X to administer my Debian systems. I don't run it as KR> root though. I use emacs TRAMP to use sudo to edit files as root on KR> the local machine. On remote machines I do the same but in an ssh KR> session in xterm (I don't use mouse or menu bars in emacs in X KR> anyway). I'm a safe sex fan myself, however there are limits to how much I am willing to sacrifice that raw feel. KR> Looking at bug 633652, have you tried running X programs as root with KR> sux or gksu instead of su? http://packages.debian.org/squeeze/sux KR> http://packages.debian.org/squeeze/gksu Mmmm, sounds kinky, but at my age I don't think we can teach this old dog new tricks. But I suppose that's what the younger generation will use and just mark this bug wontfix. Alas, no family values.
--On Tuesday, August 23, 2011 08:35:58 AM +0800 jidanni@jidanni.org wrote: If you are truly using the console then it is likely that some of the issues have nothing to do with emacs and everything to do with the console terminal emulation. At a base level emacs is depending on escape sequences to move the cursor around, but I expect it is doing a lot fancier things that only a good terminal emulator will keep up with. And I would add that I don't really want anyone working on improving console terminal emulation---there are too many other things to do that need to be done and no one spends much time on the console these days. As a side note I really hate modal editors like vi and its decendents, but I know enough of it to be able to work on consoles when emacs is not installed yet or the terminal emulation is not up to it. It is just part of managing the system in my view. Finally, when I am editing text I find that a mouse slows everything down. I do just fine with character cell xterms and no mouse. I do think it is worth getting color to work when possible. The syntax highlighting helps me spot stupid errors early. Bill
r> The console mode has been a shock. There is no mouse at all. I
r> cannot navigate the menus as usual, menu-bar-open is weird and
r> unfriendly. But, worst of all, some key combinations do not work
r> well.
0> In article <87ty99otg1.fsf@jidanni.org>,
0> jidanni <URL:mailto:jidanni@jidanni.org> ("Jidanni") wrote:
Jidanni> My question is how do all those high powered Debian Developers
Jidanni> cope? Don't tell me they don't use emacs. Or not as root.
Jidanni> Not even when administering their system?
I certainly avoid running programs as large and extensible as emacs when
I'm root! And, generally, all X11 programs fall into that category.
As previously mentioned, Tramp is the ultimate saviour for editing files
as many users on many systems.
If you feel you must run as root, and you want to use a mouse with emacs
in XTerm, then xterm-mouse-mode may help:
/--------
| xterm-mouse-mode is an interactive autoloaded Lisp function in `xt-mouse'.
| (xterm-mouse-mode &optional arg)
|
| Toggle XTerm mouse mode.
| With prefix arg, turn XTerm mouse mode on if arg is positive, otherwise
| turn it off.
|
| Turn it on to use Emacs mouse commands, and off to use xterm mouse
| commands. This works in terminal emulators compatible with xterm. It
| only works for simple uses of the mouse. Basically, only non-modified
| single clicks are supported. When turned on, the normal xterm mouse
| functionality for such clicks is still available by holding down the
| SHIFT key while pressing the mouse button.
\--------
Yes sux work with both emacs and firefox And for middle ages dog (not oldtimer) they are the ssh -X root@localhost trick Bastien
Bastien ROUCARIES <roucaries.bastien@gmail.com> (23/08/2011): or: sudo XAUTHORITY=~/.Xauthority wireshark Mraw, KiBi.
I am now officially pleased with sux, enabling me to use X programs as root despite http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633652 . Thanks everybody. Have a song, http://www.youtube.com/watch?v=gLtzQXTHiqk&list=PL38C412C876528CCB
jidanni@jidanni.org writes: The mouse should work in Emacs over SSH from an xterm. Try (xterm-mouse-mode 1). It works for me. There's also a mode to make the mouse work from a Linux console, if gpm is running. I haven't used it in a long time. Look around for t-mouse.el.
found 633652 1.2.1-5+lenny1 forwarded 633652 https://bugs.freedesktop.org/show_bug.cgi?id=39720 severity 633652 normal thanks This bug is not a security vulnerability and does not break unrelated applications. The fact that Gtk apps now connect to D-Bus makes them a related application; the reason you've only seen this recently is probably that increasingly many Gtk apps connect to D-Bus. I think this may be caused by upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=39720 which is being worked on. That bug has existed ever since dbus was written, so marking this as found in the oldest version Debian cares about (oldstable). Kenyon Ralph writes: Yes, this is good advice; any tool that clears most environment variables should work. If you don't clear environment variables, then your ordinary user account is trivially root-equivalent anyway (for instance via LD_PRELOAD, or for Gtk apps, GTK_MODULES) so there's little point in having privilege separation at all. sudoedit is another good way to edit system configuration files (it copies the file to /var/tmp as root, edits that copy of the file as your unprivileged uid, then copies back it into place as root). The emacs TRAMP facility that Kenyon Ralph mentions seems an equally good approach. When run from the (Debian, GNOME, KDE etc.) menu, system administration apps like synaptic either run under su-to-root, which invokes gksu, sux or an assortment of others; or, more commonly in recent applications, act as an unprivileged front-end to a privileged system service. jidanni writes: ... Comments like this *reduce* my motivation to fix your pet bugs. If you want people to fix things for you, please be polite. Insulting volunteer developers is not a good way to motivate them to help you. S
OK thanks... all I know is I now use sux and am back in business.
Dear 633652, sux now sux due to 659878.