On Sun, 13 Dec 2015 22:28:41 -0300 Edilson Azevedo <edilso...@aim.com>
wrote:
> Package: gnome
> Version: 1:3.14+3
> Severity: critical
> Justification: causes serious data loss
>
> *** Scenario ***
>
> Non-classic gnome logged as a regular user and some root windows
open. e.g.
> synaptic, nautilus-as-root, root-terminal, etc.
>
> *** Causing the problem ***
>
> Hitting the upper left corner of the screen with mouse cursor - or -
clicking
> over Activities.
>
> *** Problem ***
>
> Screen freezes (no usual shrink) cursor moves. No reaction to clicks.
>
> *** Observation ***
>
> top, running on a <ctrl><alt><F1-6> text window shows
gnome-settings-daemon
> busy (50%).
>
> Logs like syslog, messages, etc. get huge filled with several
messages like
> below:
>
> <<< gnome-session[1367]: (gnome-settings-daemon:1434): dconf-CRITICAL **:
> unable to create file '/run/user/1000/dconf/user': Access denied.
dconf will
> not work properly. >>>
>
> ls -l /run/user/1000/dconf/user --> -rw------- 1 root root 2 Dec 13 21:42
> /run/user/1000/dconf/user !!!
> rebooting:
> ls -l /run/user/1000/dconf/user --> -rw------- 1 user user 2 Dec 13 21:54
> /run/user/1000/dconf/user
>
> *** My conclusion ***
>
> For some reason the owner of the file referred above turns from user
to root.
> >From this moment on gnome system is desperately trying to access it
as user,
> overloading the machine, filling logs with same message, and no escape.
>
> *** My comments ***
>
> 1) As I don't know which part of software is responsible for
> /run/user/1000/dconf/user writing and creation I blame gnome.
> 2) It can be harmful to the system because when one doesn't what to
do, he/she
> will press reset button and get corrupted files.
> 3) A workaround for the crash is to hit <ctrl><alt><F1-6> and
<ctrl><alt><del>.
> 4) By now, when I need work as root, I hit <ctrl><alt><F1-6> and
startx. Some
> say it might lead to safety problems ...
>
> Thanks for your patience, anyway, I believe solution is closer.
Well you should never start a X session as root, as you mentioned, this
has security implications.
Can you still reproduce this now?
Are you using systemd as PID 1? If I'm not wrong, /run/user/<UID> is
created by logind. What is loginctl and loginctl show-session
<session-number> showing you?
Cheers,
Laurent Bigonville