Bug#766464: gksu pluma <any_file> sets the ownership of /run/user/1000/dconf/user to root:root

Linas Vepstas linasvepstas at gmail.com
Sun Nov 2 23:19:29 UTC 2014


I'll continue the conversation here, as its not clear where else to purse
it, for now.

But first: see also
https://github.com/mate-desktop/mate-settings-daemon/issues/44 -- this bug
blows through all available system ram in under 5 minutes, then dies in
swap, so its serious (for me).

Next: Running pluma as root is enough to trigger it.  No need to gksu.
What's bizarre is that, even though I am launching pluma as *root*, it
still clobbered my user uid ... How did it even find that?  (OK -- so I'm
running mate-terminal, then su - root atthe bash prompt, then pluma atthe
root prompt).

To see what's happening, I tried ltrace -S  -o tr.out pluma xxx  which
results in 1.5MB of trace.  (else I'd attach it to this email). So I see
the below. (Note my uid is 500, not 1000 as would usually be the case)

There are 3 places where /run/user/500/dconf/user appears.  An abridged
summary below. It happens very very early:

__libc_start_main(0x427590, 2, 0x7fff8bfb2c78, 0x477240 <unfinished ...>
...etc...
g_getenv(0x478ed4, 0x7fff8bfb2c78, 0x7fff8bfb2c90, 0) = 0
...etc...
SYS_lstat("/usr/share/themes/Mint-X/gtk-2.0"..., 0x7fff8bfb2690) = 0
SYS_open("/usr/share/themes/Mint-X/gtk-2.0"..., 0, 00) = 7
SYS_read(7, "style "frame"\n{\n    xthickness ="..., 4000) = 728
SYS_access("/usr/share/themes/Mint-X/gtk-2.0"..., 00) = -2
...etc...
g_key_file_new(0x477598, 0x7fff8bfb2b08, 1, 0 <unfinished ...>
SYS_open("/usr/share/locale/locale.alias", 0, 0666)  = 6

<... g_key_file_new resumed> )                       = 0x1dd1050
g_key_file_load_from_file(0x1dd1050, 0x477598, 0, 0x7fff8bfb2b08
<unfinished ...>

SYS_open("/usr/share/applications/pluma.de"..., 0, 00) = 6
SYS_fstat(6, 0x7fff8bfb19c0)                         = 0
SYS_read(6, "[Desktop Entry]\nName=Text Editor"..., 4096) = 4096
... etc...
SYS_open("/usr/share/locale-langpack/en.UT"..., 0, 00) = -2
SYS_open("/usr/share/locale-langpack/en.ut"..., 0, 00) = -2
SYS_open("/usr/share/locale-langpack/en/LC"..., 0, 00) = -2
SYS_close(6)                                         = 0
<... g_key_file_load_from_file resumed> )            = 1
g_key_file_has_group(0x1dd1050, 0x483939, 0x7fff8bfb2b08, -1) = 1
g_key_file_get_value(0x1dd1050, 0x483939, 0x4839b6, 0) = 0
g_malloc0(40, 3, 0x7fae3ce5c310, 0x7fae3ce5c310)     = 0x1d912e0
g_path_is_absolute(0x477598, 0x7fae3c357768, 40, 5)  = 1
g_filename_to_uri(0x477598, 0, 0, 5)                 = 0x1d912a0
...etc...
g_settings_new(0x47cb17, 2752, 24, 3 <unfinished ...>
SYS_open("/usr/share/glib-2.0/schemas/gsch"..., 0, 00) = 6
SYS_fstat(6, 0x7fff8bfb2560)                         = 0
...etc...
SYS_open("/etc/dconf/profile/user", 0, 0666)         = -2
SYS_open("/usr/local/share/dconf/profile/u"..., 0, 0666) = -2
SYS_open("/usr/share/dconf/profile/user", 0, 0666)   = -2
SYS_access("/run", 00)                               = 0
SYS_stat("/run", 0x7fff8bfb2580)                     = 0
SYS_access("/run/user", 00)                          = 0
SYS_stat("/run/user", 0x7fff8bfb2580)                = 0
SYS_access("/run/user/500", 00)                      = 0
SYS_stat("/run/user/500", 0x7fff8bfb2580)            = 0
SYS_access("/run/user/500/dconf", 00)                = 0
SYS_stat("/run/user/500/dconf", 0x7fff8bfb2580)      = 0
SYS_open("/run/user/500/dconf/user", 66, 0600)       = 6
SYS_pwrite(6, 0x7fae36268bee, 1, 1)                  = 1
SYS_mmap(0, 1, 1, 1)                                 = 0x7fae3f1f8000
SYS_close(6)                                         = 0
SYS_open("/root/.config/dconf/user", 0, 00)          = 6
SYS_fstat(6, 0x7fff8bfb2560)                         = 0
SYS_mmap(0, 515, 1, 2)                               = 0x7fae3f1f0000
SYS_close(6)                                         = 0


The other two places are similar.:

g_settings_get_strv(0x1dd10d0, 0x47c1e1, 893, 0x47ce60 <unfinished ...>
SYS_munmap(0x7fae3f1f0000, 515)                      = 0
SYS_munmap(0x7fae3f1f8000, 1)                        = 0
SYS_access("/run", 00)                               = 0
SYS_stat("/run", 0x7fff8bfb23f0)                     = 0
SYS_access("/run/user", 00)                          = 0
SYS_stat("/run/user", 0x7fff8bfb23f0)                = 0
SYS_access("/run/user/500", 00)                      = 0
SYS_stat("/run/user/500", 0x7fff8bfb23f0)            = 0
SYS_access("/run/user/500/dconf", 00)                = 0
SYS_stat("/run/user/500/dconf", 0x7fff8bfb23f0)      = 0
SYS_open("/run/user/500/dconf/user", 66, 0600)       = 11
SYS_pwrite(11, 0x7fae36268bee, 1, 1)                 = 1
SYS_mmap(0, 1, 1, 1)                                 = 0x7fae3f1f8000
SYS_close(11)                                        = 0


So: the very first access is very very early during gtk initialization.  I
don't undertand how it found my uid?  Did it look at who forked the bash
shell ??
I also do not see where it is actually changing the file perms  but the
equivalent strace is more clear:

open("/run/user/500/dconf/user", O_RDWR|O_CREAT, 0600) = 13
pwrite(13, "\0", 1, 1)                  = 1
mmap(NULL, 1, PROT_READ, MAP_SHARED, 13, 0) = 0x7f0b86630000
close(13)                               = 0

So: the CREAT is bad news, if the file doesn't exist: it gets created as
root.  So that's obviously bad.

If the file does exist .. its mmaped ... who else is mmaping this file?
what's it for?

Beats me ... investigating more ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-mate-team/attachments/20141102/d7083d39/attachment-0001.html>


More information about the pkg-mate-team mailing list