Mint Software Manager messes up permissions on /run/user/1000/dconf/user about mintinstall HOT 17 CLOSED

I'm attaching a terminal trace illustrating the permissions problem:
hritcu@detained ~ $ ls -l /run/user/1000/dconf/user
ls: cannot access /run/user/1000/dconf/user: No such file or directory
[2]hritcu@detained ~ $ gksu mintinstall
glibtop: Non-standard uts for running kernel:
release 3.11-2-amd64=3.11.0 gives version code 199424

No bp log location saved, using default.
[000:000] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:000] Computer model: Not available
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:000] Using Gtk2 toolkit
No bp log location saved, using default.
[000:000] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:000] Computer model: Not available
[000:002] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:002] No bp log location saved, using default.
[000:002] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:002] Computer model: Not available
[000:002] Browser XEmbed support present: 1
[000:002] Browser toolkit is Gtk2.
[000:003] Using Gtk2 toolkit
[000:002] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:002] No bp log location saved, using default.
[000:002] Cpu: 6.60.3, x8, 2401Mhz, 15763MB
[000:002] Computer model: Not available
add_categories took 0.522 ms
build_matched_packages took 0.121 ms
java version "1.7.0_21"
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-5)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
add_packages took 2175.822 ms
add_reviews took 308.270 ms
init took 2913.610 ms
show_category took 3.648 ms
Killed
hritcu@detained ~ $ ls -l /run/user/1000/dconf/user
-rw------- 1 root root 2 Mar 8 17:39 /run/user/1000/dconf/user

from mintinstall.

One thing to note is that I can reproduce this most reliably when /run/user/1000/dconf/user doesn't already exist. So deleting /run/user/1000/dconf/user and then starting mintinstall is my most reliable way of reproducing. The problem does however sometimes (but not all the time) happen when starting mintinstall with an existing file having the right permissions -- i.e. a much more realistic scenario.

from mintinstall.

Tried to use "auditctl -w /run/user/1000/dconf/user -p rwxa" to see what's happening when mintinstall changes permissions. I'm still not completely sure how to interpret this:

type=PATH msg=audit(03/08/2014 19:37:31.661:44) : item=1 name=/run/user/1000/dconf/user inode=89378 dev=00:0e mode=file,600 ouid=root ogid=root rdev=00:00 
type=PATH msg=audit(03/08/2014 19:37:31.661:44) : item=0 name=/run/user/1000/dconf/ inode=16672 dev=00:0e mode=dir,700 ouid=hritcu ogid=hritcu rdev=00:00 
type=CWD msg=audit(03/08/2014 19:37:31.661:44) :  cwd=/home/hritcu 
type=SYSCALL msg=audit(03/08/2014 19:37:31.661:44) : arch=x86_64 syscall=open success=yes exit=87 a0=0x9e6b550 a1=O_RDWR|O_CREAT a2=0600 a3=0x7fff1dd81e50 items=2 ppid=17704 pid=17705 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root ses=unset tty=(none) comm=mintinstall exe=/usr/bin/python2.7 key=(null)

from mintinstall.

I did one more experiment and it seems that when /run/user/1000/dconf/user does not exist at all, even "gksu"-ing emacs creates a file owned by root.

hritcu@detained ~ $ rm /run/user/1000/dconf/user
hritcu@detained ~ $ gksu emacs
glibtop: Non-standard uts for running kernel:
release 3.11-2-amd64=3.11.0 gives version code 199424
hritcu@detained ~ $ ls -al /run/user/1000/dconf/user
-rw------- 1 root root 2 Mar  8 22:05 /run/user/1000/dconf/user

On the other hand, I didn't yet manage to make "gksu emacs" to change the permissions when the file already existed.

hritcu@detained ~ $ sudo chown hritcu:hritcu /run/user/1000/dconf/user
hritcu@detained ~ $ gksu emacs
glibtop: Non-standard uts for running kernel:
release 3.11-2-amd64=3.11.0 gives version code 199424
hritcu@detained ~ $ ls -al /run/user/1000/dconf/user
-rw------- 1 hritcu hritcu 2 Mar  8 22:05 /run/user/1000/dconf/user

from mintinstall.

I've tried yet another experiment and none of these problems appears when mintinstall (or emacs) are started in a "sudo su -" session.

from mintinstall.

Hi,

This is an issue with systemd. It's supposed to be fixed already in LMDE. Can you confirm which version of systemd you are running?

from mintinstall.

Hi Clem,

I'm on a fresh install of the official LMDE 201403 release. I have systemd
204-5linuxmint1, which seems like the latest version. Attached a
screenshot as proof :)

Regards,
Catalin

On Wed, Mar 12, 2014 at 5:17 PM, Clement Lefebvre
[email protected]:

Hi,

This is an issue with systemd. It's supposed to be fixed already in LMDE.
Can you confirm which version of systemd you are running?

Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-37428513
.

from mintinstall.

Ok, the fix worked great in Mint 16 and it solved the sudo case in LMDE. There's obviously more at play here with gksu and maybe also pkexec. I'll look into it and see if we can fix it "more" :)

from mintinstall.

I have the same issue on LMDE Mate 64-bit, running on a Lenovo X61s. Uses 100% of RAM and fluctuating CPU up to 100% of both cores. If I kill -9 the mate-settings-daemon, within a couple of minutes it's back up to 600+MB RAM and keeps climbing until it fills my 4GB again. Obviously this is a serious problem.
This did not happen on Mint 16 Mate.
I have systemd version 204-5linuxmint1 per Synaptic. Kernel: Linux 3.11-2-amd64. MATE: 1.6.1.
$ systemd --version
systemd 204
+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ

from mintinstall.

@KBMD: workaround: http://forums.linuxmint.com/viewtopic.php?f=198&t=159793&start=20#p835353

from mintinstall.

fwiw, continues to be a problem in linux mint17 qiana, freshly installed just a week ago. .xsession-errors grew into 2GBytes and mate-settings-daemon leaks memory at the rate of 1-2GBytes/minute, thus using all system ram in under 5 minutes.

from mintinstall.

I am facing in Linux Mint 18 'Sarah' "MATE-64 bit".
In my case if i run apt
(mate-terminal:2370): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
message reappear and chock the ram till end .

from mintinstall.

Probably because systemd isn't patched anymore in Mint 18 (as opposed to Mint 17 and LMDE Betsy).

from mintinstall.

I asked linux-mint guys on irc chat they told me to not use apt instead use update manager to update the system, and they suggested me a fresh install, with linux mint sarah KDE 64 bit so i did and till now no issue faced, so i think there is something wrong introduced by me while i installed things from apt.
Thanks for help.

from mintinstall.

I'm not sure why they told you that. It's a good idea to use the Update Manager so you can "review" updates, but other than that, there's no issue with using apt directly, and it certainly won't affect your runtime directory.

The issue is related to running processes as root.

from mintinstall.

I have this problem on Mint 18.1 x64 Cinnamon. It seems to be preventing me from logging in sometimes, and it thrashes the disk like crazy. Is there a fix or workaround please? Also, compare this Debian bug report.

I note that the ostensible workaround mentioned in this thread above is . . to remove systemd. That is rather drastic.

from mintinstall.

Hello I just installed Linux Mint Cinnamon and I am new on Linux, I use at start the terminal and administration configure the firewall installed a program through terminal but suddenly I start having the error that my authentication was unsuccessful even on terminal says I am not allowed, I can not access Administration and basically do nothing more as I have no more access I am not sure what caused that I am not allowed also to adduser so wondering is I need reinstall the system or there is any place maybe in /run/NetworkManager/resolv.config? Thansk thanks Mariana

from mintinstall.