Bug 1037285 - /run/user/1001/dconf/user file changes ownership to root on running gedit as root from a shell, causing GNOME Shell to lose its mind
/run/user/1001/dconf/user file changes ownership to root on running gedit as ...
Status: CLOSED DUPLICATE of bug 753882
Product: Fedora
Classification: Fedora
Component: gnome-shell (Show other bugs)
20
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Owen Taylor
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-12-03 00:16 EST by Adam Williamson
Modified: 2013-12-03 12:28 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-03 09:26:41 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fun. (52.26 KB, image/png)
2013-12-03 12:28 EST, Adam Williamson
no flags Details

  None (edit)
Description Adam Williamson 2013-12-03 00:16:23 EST
This may be a nightmare to debug, but I've hit it at least twice now, so it seems worth reporting to see if we can possibly track it down :/ This is on F20, my main desktop system.

Close as I can tell, both times it's happened while building a live image with livecd-creator. Suddenly gnome-shell becomes unresponsive. If I ssh in from another system, I see it consuming 100% CPU; strace shows it trying to read /run/user/1001/dconf/user over and over:

close(-1)                               = -1 EBADF (Bad file descriptor)
open("/home/adamw/.config/dconf/user", O_RDONLY) = 26
fstat(26, {st_mode=S_IFREG|0644, st_size=75655, ...}) = 0
mmap(NULL, 75655, PROT_READ, MAP_PRIVATE, 26, 0) = 0x7f1ec4073000
close(26)                               = 0
munmap(0x7f1ec4073000, 75655)           = 0
access("/run", F_OK)                    = 0
stat("/run", {st_mode=S_IFDIR|0755, st_size=520, ...}) = 0
access("/run/user", F_OK)               = 0
stat("/run/user", {st_mode=S_IFDIR|0755, st_size=120, ...}) = 0
access("/run/user/1001", F_OK)          = 0
stat("/run/user/1001", {st_mode=S_IFDIR|0700, st_size=220, ...}) = 0
access("/run/user/1001/dconf", F_OK)    = 0
stat("/run/user/1001/dconf", {st_mode=S_IFDIR|0700, st_size=60, ...}) = 0
open("/run/user/1001/dconf/user", O_RDWR|O_CREAT, 0600) = -1 EACCES (Permission denied)
write(2, "\n(gnome-shell:27046): dconf-CRIT"..., 142) = 142
close(-1)                               = -1 EBADF (Bad file descriptor)
open("/home/adamw/.config/dconf/user", O_RDONLY) = 26
fstat(26, {st_mode=S_IFREG|0644, st_size=75655, ...}) = 0
mmap(NULL, 75655, PROT_READ, MAP_PRIVATE, 26, 0) = 0x7f1ec4073000
close(26)                               = 0

If I kill shell and let it restart, it gets stuck in the same state.

I believe the file's supposed to be owned by the user (1001 is my regular user account), but it isn't:

[root@adam adamw]# ls -l /run/user/1001/dconf/user 
-rw-------. 1 root root 2 Dec  2 20:47 /run/user/1001/dconf/user

There is something interesting in the journal around 20:47:

Dec 02 20:47:35 adam.happyassassin.net gnome-session[2027]: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x2e00029 (live.py.32)
Dec 02 20:47:35 adam.happyassassin.net gnome-session[2027]: Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

'live.py' is part of python-imgcreate, part of livecd-creator; it's a pure command-line tool, though, no GUI, so not exactly sure how it fits in.

If I wipe the file and kill the stuck shell process it auto-respawns successfully. The file is created again, now owned by my user (1001).

So, er...any ideas?
Comment 1 Adam Williamson 2013-12-03 00:19:43 EST
ooh, actually, I think I didn't have livecd-creator running at the time of the latest one: I had a copy of gedit running as root, with the file 'live.py.32bituefi' open. THAT makes a lot more sense.
Comment 2 Colin Walters 2013-12-03 09:26:41 EST

*** This bug has been marked as a duplicate of bug 753882 ***
Comment 3 Colin Walters 2013-12-03 09:27:50 EST
(In reply to Adam Williamson from comment #1)
> I had a copy of gedit running as root, 

Don't do that.
Comment 4 Adam Williamson 2013-12-03 12:24:14 EST
Fine. Implement something with PolicyKit so I can use a graphical editor on system files in a cleaner way. We've only had it for half a decade or so.
Comment 5 Adam Williamson 2013-12-03 12:28:45 EST
Created attachment 832218 [details]
fun.

In other words: you fix this, and I'll stop running gedit as root.

Note You need to log in before you can comment on or make changes to this bug.