GNU bug report logs -
#32413
25.2; When run as root, emacs writes dconf files in a non-root user's /run/user/XXX directory
Previous Next
Reported by: Vincent Lefevre <vincent <at> vinc17.net>
Date: Fri, 10 Aug 2018 09:31:02 UTC
Severity: normal
Tags: notabug
Found in version 25.2
Done: Noam Postavsky <npostavs <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32413 in the body.
You can then email your comments to 32413 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 09:31:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Vincent Lefevre <vincent <at> vinc17.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 10 Aug 2018 09:31:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Original bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891063
In summary:
Just after one logs in, does a "su" and runs Emacs, Emacs writes
dconf files in a non-root user's /run/user/XXX directory (related
to DBUS_SESSION_BUS_ADDRESS or XDG_RUNTIME_DIR). I got:
zira:~> ll /run/user/1000
total 0
srw-rw-rw- 1 vinc17 vinc17 0 2018-02-22 04:02:21 bus=
drwx------ 3 vinc17 vinc17 60 2018-02-22 04:02:21 dbus-1/
drwx------ 2 root root 60 2018-02-22 04:02:32 dconf/
^^^^^^^^^^^
drwx------ 2 vinc17 vinc17 140 2018-02-22 04:02:21 gnupg/
drwx------ 2 vinc17 vinc17 40 2018-02-22 04:03:28 gvfs/
drwx------ 2 vinc17 vinc17 80 2018-02-22 04:02:21 pulse/
drwxr-xr-x 2 vinc17 vinc17 80 2018-02-22 04:02:21 systemd/
Unsurprisingly, this then yields issues when one runs Emacs
as a normal user:
(emacs:8958): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
[...]
Emacs should never create files/directories if the user hasn't
explicitly asked it to do that, in particular if this is under
a directory owned by a different user.
In GNU Emacs 25.2.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2018-07-11, modified by Debian built on x86-ubc-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12000000
System Description: Debian GNU/Linux stable-updates (sid)
Configured using:
'configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --build x86_64-linux-gnu
--prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.2/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --without-gconf --with-x=yes --with-x-toolkit=gtk3
--with-toolkit-scroll-bars 'CFLAGS=-g -O2
-fdebug-prefix-map=/build/emacs25-cfFROJ/emacs25-25.2+1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall'
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11
Important settings:
value of $LC_COLLATE: POSIX
value of $LC_CTYPE: en_US.UTF-8
value of $LC_TIME: en_DK
value of $LANG: POSIX
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
display-time-mode: t
show-paren-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done
Loading /etc/emacs/site-start.d/50rnc-mode.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done
Loading /etc/emacs/site-start.d/50why3.el (source)...done
Loading /home/vinc17/share/emacs/site-lisp/mutteditor.el (source)...done
Loading time...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Load-path shadows:
/usr/share/emacs/25.2/site-lisp/why3 hides /usr/share/emacs/site-lisp/why3
/usr/share/emacs/25.2/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs25/site-lisp/cmake-data/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/25.2/lisp/textmodes/rst
/usr/share/emacs25/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/25.2/lisp/language/thai-word
Features:
(shadow sort mail-extr warnings emacsbug message dired format-spec
rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
mail-prsvr mail-utils time cus-start cus-load paren cc-styles cc-align
cc-engine cc-vars cc-defs edmacro kmacro cl-loaddefs pcase cl-lib
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)
Memory information:
((conses 16 107170 5004)
(symbols 48 22452 0)
(miscs 40 55 113)
(strings 32 20688 4143)
(string-bytes 1 602044)
(vectors 16 12882)
(vector-slots 8 443217 3065)
(floats 8 171 101)
(intervals 56 267 0)
(buffers 976 18))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 12:18:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 32413 <at> debbugs.gnu.org (full text, mbox):
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Date: Fri, 10 Aug 2018 11:30:09 +0200
>
> Emacs should never create files/directories if the user hasn't
> explicitly asked it to do that
I don't agree with this principle, not in this general form. (The "in
a directory owned by another user" part, to which I think I agree, as
written, was not a qualification for this general statement, so it
doesn't count for the purposes of the principle itself.)
As just one random example of what Emacs "should never do", we write
the customizations to a file "without the user's explicit request".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 12:29:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 32413 <at> debbugs.gnu.org (full text, mbox):
Vincent Lefevre <vincent <at> vinc17.net> writes:
> Emacs should never create files/directories if the user hasn't
> explicitly asked it to do that, in particular if this is under
> a directory owned by a different user.
Does it help if you ./configure --without-gsettings?
(maybe it should default to off, I'm not sure what gsettings is actually
good for apart from causing bugs, e.g., #25228)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 12:40:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 32413 <at> debbugs.gnu.org (full text, mbox):
> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Fri, 10 Aug 2018 08:28:49 -0400
> Cc: 32413 <at> debbugs.gnu.org
>
> Vincent Lefevre <vincent <at> vinc17.net> writes:
>
> > Emacs should never create files/directories if the user hasn't
> > explicitly asked it to do that, in particular if this is under
> > a directory owned by a different user.
>
> Does it help if you ./configure --without-gsettings?
So you are saying that it's the Gsettings functions that write to that
directory, outside of Emacs's control?
> (maybe it should default to off, I'm not sure what gsettings is actually
> good for apart from causing bugs, e.g., #25228)
I might agree, but then won't too many users be annoyed by Emacs not
following desktop-wide customizations?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 12:59:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 32413 <at> debbugs.gnu.org (full text, mbox):
On 2018-08-10 15:17:26 +0300, Eli Zaretskii wrote:
> > From: Vincent Lefevre <vincent <at> vinc17.net>
> > Date: Fri, 10 Aug 2018 11:30:09 +0200
> >
> > Emacs should never create files/directories if the user hasn't
> > explicitly asked it to do that
>
> I don't agree with this principle, not in this general form. (The "in
> a directory owned by another user" part, to which I think I agree, as
> written, was not a qualification for this general statement, so it
> doesn't count for the purposes of the principle itself.)
>
> As just one random example of what Emacs "should never do", we write
> the customizations to a file "without the user's explicit request".
I don't understand why there is anything to write if the user
hasn't customized anything. And if the user introduces some
customization, then this can be regarded as an explicit write
operation (due to the action of the user in this sense).
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 13:48:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 32413 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 10 Aug 2018 14:57:58 +0200
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Cc: 32413 <at> debbugs.gnu.org
>
> > > Emacs should never create files/directories if the user hasn't
> > > explicitly asked it to do that
> >
> > I don't agree with this principle, not in this general form. (The "in
> > a directory owned by another user" part, to which I think I agree, as
> > written, was not a qualification for this general statement, so it
> > doesn't count for the purposes of the principle itself.)
> >
> > As just one random example of what Emacs "should never do", we write
> > the customizations to a file "without the user's explicit request".
>
> I don't understand why there is anything to write if the user
> hasn't customized anything.
That was just an example of something that doesn't explicitly ask for
writing a file. Another example is Eshell: when it exits, it writes
files in the ~/.eshell directory.
More generally, certain Emacs features might write files "without user
explicitly asking" as part of providing some feature that needs to be
persistent between sessions. I think that's quite allright, which is
why I disagree with the general principle you were trying to
establish.
> And if the user introduces some customization, then this can be
> regarded as an explicit write operation (due to the action of the
> user in this sense).
Well, in that case, let's regard user using dconf as an explicit write
permission ;-)
Seriously, though: if your principle can be subverted in some
situations, then we need to define what situations are those. In
particular, how is what you report different from what Eshell does on
exit?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 14:18:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 32413 <at> debbugs.gnu.org (full text, mbox):
On 2018-08-10 08:28:49 -0400, Noam Postavsky wrote:
> Vincent Lefevre <vincent <at> vinc17.net> writes:
>
> > Emacs should never create files/directories if the user hasn't
> > explicitly asked it to do that, in particular if this is under
> > a directory owned by a different user.
>
> Does it help if you ./configure --without-gsettings?
Yes, this solves the problem (according to strace).
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 14:33:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 32413 <at> debbugs.gnu.org (full text, mbox):
On 2018-08-10 16:47:17 +0300, Eli Zaretskii wrote:
> That was just an example of something that doesn't explicitly ask for
> writing a file. Another example is Eshell: when it exits, it writes
> files in the ~/.eshell directory.
If you mean that it writes the history, then that's a usual shell
thing, so that's OK. BTW, that's probably one of the reasons why
"su" redefines HOME to the target user home directory by default.
I suppose that caches could be OK too as long as they are written
in a "safe" place.
> More generally, certain Emacs features might write files "without user
> explicitly asking" as part of providing some feature that needs to be
> persistent between sessions. I think that's quite allright, which is
> why I disagree with the general principle you were trying to
> establish.
Perhaps.
But, for instance, writing a default .emacs would not be OK and would
require at least user confirmation.
> > And if the user introduces some customization, then this can be
> > regarded as an explicit write operation (due to the action of the
> > user in this sense).
>
> Well, in that case, let's regard user using dconf as an explicit write
> permission ;-)
>
> Seriously, though: if your principle can be subverted in some
> situations, then we need to define what situations are those. In
> particular, how is what you report different from what Eshell does on
> exit?
So, perhaps this should be on a case by case basis. I don't know about
dconf, but in that case, this doesn't seem to be correct. And if not
writing under $HOME, I think that the owner of the directory should be
checked in some cases.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 15:42:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 32413 <at> debbugs.gnu.org (full text, mbox):
Vincent Lefevre wrote:
> If you mean that it writes the history, then that's a usual shell
> thing, so that's OK.
The behaviour you complain about in the subject line is a usual X thing,
for "modern" (ie non-ancient) desktop applications, as was explained in
the referenced Debian bug reports you were pointed to.
> BTW, that's probably one of the reasons why "su" redefines HOME to the
> target user home directory by default.
And it's one of the reasons why the referenced reports discouraged
running desktop applications under plain "su". I'm sure in one of the
reports someone suggested modifying plain "su".
The specific example of dconf etc is not a bug, it's how these things
work. If you don't like it, use the configure option to disable that
feature (most programs won't give you that option). I think the general
principle of "Emacs should never create files/directories if the user
hasn't explicitly asked it to do that" is a non-starter.
So this report should be closed wontfix IMO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 15:54:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 32413 <at> debbugs.gnu.org (full text, mbox):
On 2018-08-10 11:41:30 -0400, Glenn Morris wrote:
> Vincent Lefevre wrote:
> > If you mean that it writes the history, then that's a usual shell
> > thing, so that's OK.
>
> The behaviour you complain about in the subject line is a usual X thing,
> for "modern" (ie non-ancient) desktop applications, as was explained in
> the referenced Debian bug reports you were pointed to.
But Emacs has been an ancient desktop application. Now, one has a
regression.
> > BTW, that's probably one of the reasons why "su" redefines HOME to the
> > target user home directory by default.
>
> And it's one of the reasons why the referenced reports discouraged
> running desktop applications under plain "su". I'm sure in one of the
> reports someone suggested modifying plain "su".
This would make sense to follow the principle of plain "su"
(e.g. HOME is redefined...).
> The specific example of dconf etc is not a bug, it's how these things
> work. If you don't like it, use the configure option to disable that
> feature (most programs won't give you that option). I think the general
> principle of "Emacs should never create files/directories if the user
> hasn't explicitly asked it to do that" is a non-starter.
> So this report should be closed wontfix IMO.
I'm using Debian's package. So, you are saying that Debian should
use this option?
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Fri, 10 Aug 2018 19:41:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 32413 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 32413 <at> debbugs.gnu.org
> Date: Fri, 10 Aug 2018 11:41:30 -0400
>
> So this report should be closed wontfix IMO.
I tend to agree. This report seems to be about standard behavior of
desktop-aware applications. Emacs just behaves like any other app
does in this case. And the code which determines this behavior is not
in Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Sun, 12 Aug 2018 17:30:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 32413 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Does it help if you ./configure --without-gsettings?
>> (maybe it should default to off, I'm not sure what gsettings is actually
>> good for apart from causing bugs, e.g., #25228)
>
> I might agree, but then won't too many users be annoyed by Emacs not
> following desktop-wide customizations?
Hmm, yeah, we would need at least some feedback from users who actually
use a full desktop environment (GNOME, I guess?) before changing this.
For myself, I just run a simple window manager, so the concept of
"desktop-wide customization" is fairly meaningless on my system.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Sun, 12 Aug 2018 17:33:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 32413 <at> debbugs.gnu.org (full text, mbox):
tags 32413 notabug
close 32413
quit
>> The specific example of dconf etc is not a bug, it's how these things
>> work. If you don't like it, use the configure option to disable that
>> feature (most programs won't give you that option). I think the general
>> principle of "Emacs should never create files/directories if the user
>> hasn't explicitly asked it to do that" is a non-starter.
>> So this report should be closed wontfix IMO.
>
> I'm using Debian's package. So, you are saying that Debian should
> use this option?
You should either stop using Debian's package (since you don't like the
options they choose), or see if you can convince them to use that
option.
I think it's clear enough that ./configure --without-gsettings is as
much of a fix as there's ever going to be, so I'm closing this bug.
Added tag(s) notabug.
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sun, 12 Aug 2018 17:33:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
32413 <at> debbugs.gnu.org and Vincent Lefevre <vincent <at> vinc17.net>
Request was from
Noam Postavsky <npostavs <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Sun, 12 Aug 2018 17:33:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Sun, 12 Aug 2018 22:04:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 32413 <at> debbugs.gnu.org (full text, mbox):
On Aug 12 2018, Noam Postavsky <npostavs <at> gmail.com> wrote:
> You should either stop using Debian's package (since you don't like the
> options they choose), or see if you can convince them to use that
> option.
Or maybe even better, use Tramp instead of running Emacs as root.
Andreas.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#32413
; Package
emacs
.
(Sun, 12 Aug 2018 23:46:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 32413 <at> debbugs.gnu.org (full text, mbox):
Vincent Lefevre wrote:
> I'm using Debian's package. So, you are saying that Debian should
> use this option?
No. IMO the Debian bug should also be closed wontfix.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 10 Sep 2018 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 72 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.