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
Summary: /run/user/1001/dconf/user file changes ownership to root on running gedit as ...
Keywords:
Status: CLOSED DUPLICATE of bug 753882
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 20
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-03 05:16 UTC by Adam Williamson
Modified: 2013-12-03 17:28 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-03 14:26:41 UTC
Type: Bug
Embargoed:


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

Description Adam Williamson 2013-12-03 05:16:23 UTC
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 05:19:43 UTC
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 14:26:41 UTC

*** This bug has been marked as a duplicate of bug 753882 ***

Comment 3 Colin Walters 2013-12-03 14:27:50 UTC
(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 17:24:14 UTC
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 17:28:45 UTC
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.