After using sudo some files now owned by root

Bug #1374917 reported by Axel Waldheim
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ubuntu MATE
Won't Fix
Low
Unassigned
systemd-shim (Ubuntu)
New
Undecided
Unassigned

Bug Description

After I changed a file with sudo now include some files in my home directory root.

axelw@work2:~$ sudo pluma /etc/lightdm/lightdm.conf
[sudo] password for axelw:

... edited and saved file ...

axelw@work2:~$ find ./ -user root
./.cache/dconf/user
./.local/share/recently-used.xbel
./.config/dconf/user
./.config/pluma/pluma.ini

Revision history for this message
nadrimajstor (ipejic) wrote :

Isn't that a correct behavior by design? Aren't we suppose to run graphical commands that need root using `gksudo`?

Revision history for this message
Axel Waldheim (axel-waldh) wrote :

Actually that would be gksudo to use a step backwards, under Ubuntu 12.04, there is not a problem. The files are not modified to Owner 'root'.
If I 'gksudo ...' use, I always have to enter my password, with 'sudo ...' only once.

Even if I 'sudo -s' use, the owner is changed to 'root':
axelw@work2:~$ sudo -s
[sudo] password for axelw:
root@work2:~# pwd
/home/axelw
root@work2:~# chown -R axelw:axelw /home/axelw
root@work2:~# pluma /etc/lightdm/lightdm.conf
...
root@work2:~# find /home/axelw -user root
/home/axelw/.local/share/recently-used.xbel
/home/axelw/.config/pluma/pluma.ini

Revision history for this message
nadrimajstor (ipejic) wrote :

Looking at the man pages, `gksu` and `gksudo` was always a option for running graphical apps with elevated privileges as `sudo` will give root privileges but will retain current user environment.
Upstream offered a PolicyKit based gksu https://wiki.gnome.org/action/show/Apps/Attic/gksu?action=show&redirect=gksu as a better option, however due to not being maintained and having open CVEs for long time, after 12.04, gksu-polkit package was dropped https://bugs.launchpad.net/ubuntu/+source/gksu-polkit/+bug/1172339.
So, options are:
a)
$ gksudo pluma

b)
$ sudo -i
# pluma

c)
$ sudo su - root
# pluma

Revision history for this message
Axel Waldheim (axel-waldh) wrote :

Thanks for the information, now I have found a good solution for me:
axelw@work2:~$ sudo -i pluma /etc/lightdm/lightdm.conf
[sudo] password for axelw:
...
axelw@work2:~$

Written in one line is used by root environment, but after the end of the command I'm 'axelw' again.

nadrimajstor (ipejic)
Changed in ubuntu-mate:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
Martin Wimpress  (flexiondotorg) wrote :

There appears to be a bug in the Ubuntu systemd shim implementation, the following upstream bugs all describe the issue.

 * https://github.com/mate-desktop/mate-settings-daemon/issues/44
 * https://bugzilla.redhat.com/show_bug.cgi?id=753882
 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766464

I'll try to find the correct place to file this issue, but it is not a bug in MATE.

summary: - After use sudo (pluma) file owner now root
+ After using sudo some files now owned by root
Revision history for this message
Martin Wimpress  (flexiondotorg) wrote :

This is not a bug in MATE itself. If the XDG_* variables are not set then it is not the receiving applications fault.

I have tested on Arch Linux with "proper" systemd 218-1 and the issue of file ownership in the the users `.config` home directory being changed to `root` is not present. I can reliably reproduce this on Ubuntu 14.04 running systemd-shim, so I can only assume the root cause lies in systemd-shim.

Changed in ubuntu-mate:
status: Confirmed → Won't Fix
Revision history for this message
Vlad Orlov (monsta) wrote :

https://bugs.debian.org/766464 is a different bug - I don't have systemd-shim installed and the /run/user/1000/dconf/user file still gets owned by root when I run pluma via gksu. In addition, the files in my home dir aren't affected by that bug at all.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.