Oopsie with sudo vs gksudo? [SOLVED]

[eatenimpinia]

OK. We're not supposed to use sudo when launching a GUI application that needs root access. We're supposed to use gksudo (or possibly pkexec -- I haven't researched that yet). I found a thread that talked about finding any files we might have messed up by using sudo instead of gksudo. It said to use:

Code: Select all

find $HOME -not -user $USER -exec ls -lad {} \;

which, as far as I can see, lists all files and directories in my home directory where I'm not the owner. In my case, the result is:

Code: Select all

find $HOME -not -user $USER -exec ls -lad {} \;
drwx------ 2 root root 4096 Jul 25 14:03 /home/dave/.cache/dconf
find: `/home/dave/.cache/dconf': Permission denied
drwx------ 2 root root 4096 Jul 25 14:04 /home/dave/.config/leafpad
find: `/home/dave/.config/leafpad': Permission denied
-rw-r--r-- 1 root root 66 Jul 25 15:07 /home/dave/.selected_editor

To the best of my knowledge, I've never done anything with ....cache/dconf, ....config/leafpad, or ....selected_editor. Are those files/directories supposed to be owned by root instead of by me?

EDIT: I've found two threads saying ~/.cache/dconf and its contents should NOT be owned by root. One of them is a bug report on Ubuntu from a couple of years ago that "Expired" saying that merely using gedit changes the ownership:

https://bugs.launchpad.net/ubuntu/+sour ... ug/1315835

For ~/.config/leafpad, I found one thread saying it shouldn't be owned by root.

For ~/.selected_editor, I've found nothing.

On the assumption that I should be the owner of everything in my home directory, how do I take ownership of those directories/files? Would this be correct/safe?

Code: Select all

sudo chown $USER:$USER -R ~

Or, should I specify each directory/file individually? The permissions look OK to me. Should those be changed in any way?

[Flemur]

FWIW, pkexec doesn't work for me - says "This incident has been reported."

I own all the files under my $HOME; IIRC, there's a dconf or gconf file that doesn't like getting deleted, tho.

The other day I ran "sudo thunar" and some thunar rc/xml file got owned by root.

This should be fine:

Code: Select all

sudo chown $USER:$USER -R ~

But just to be sure(**), even though
$ sudo echo $USER
returns me, not root, I'd enter your full user name and path to your home:

Code: Select all

sudo chown -R username:username /home/username 

** Rule #1: Never trust a computer. Corollary: If you're not sure about something, don't let the computer decide.

[eatenimpinia]

Thanks for the confirmation on your owning everything under your home directory. I also took your advice about being more specific on $USER and the home directory. I ended up just doing three commands to handle my problematic directories and file:

Code: Select all

sudo chown dave:dave -R /home/dave/.cache/dconf
sudo chown dave:dave -R /home/dave/.config/leafpad
sudo chown dave:dave /home/dave/.selected_editor

That FIND command comes back clean, now.

I really don't know about that PKEXEC command. The man page seems to imply there might have to exist some kind of authentication agent. But, I haven't looked into it yet.

[eatenimpinia]

WRT to pkexec, it sure seems it has to be configured for each program we want to run via it:

https://askubuntu.com/questions/287845/ ... 847#332847

Seems a bit of a PITA as a replacement for gksudo. And, looking at other threads, that seems to be the consensus. Most people seem to just ignore the deprecation of gksudo and use it instead.

[BG405]

I get all these!:

Code: Select all

brian@SERVER ~ $ find $HOME -not -user $USER -exec ls -lad {} \;
-rw-r--r-- 1 root root 0 Apr 23 23:31 /home/brian/.local/share/.converted-launchers
drwx------ 3 root root 4096 Apr 23 23:31 /home/brian/.local/share/nautilus
find: `/home/brian/.local/share/nautilus': Permission denied
drwxr-xr-x 2 root root 4096 Apr 23 23:31 /home/brian/.config/nautilus
-rw-r--r-- 1 root root 9126 Apr 27 21:16 /home/brian/.config/nautilus/accels
drwxr-xr-x 2 root root 4096 May  7 18:54 /home/brian/.rpmdb
-rw-r--r-- 1 root root 12288 May  7 18:54 /home/brian/.rpmdb/Packages
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Obsoletename
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Basenames
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Conflictname
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Triggername
-rw-r--r-- 1 root root 286719 May  7 18:57 /home/brian/.rpmdb/__db.001
-rw-r--r-- 1 root root 110591 May  7 18:57 /home/brian/.rpmdb/__db.003
-rw-r--r-- 1 root root 81919 May  7 18:57 /home/brian/.rpmdb/__db.002
-rw-r--r-- 1 root root 0 May  7 18:54 /home/brian/.rpmdb/.dbenv.lock
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Name
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Providename
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Sigmd5
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Requirename
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Group
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Sha1header
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Installtid
-rw-r--r-- 1 root root 8192 May  7 18:54 /home/brian/.rpmdb/Dirnames
-rw-r--r-- 1 root root 5666 Jun  2 21:53 /home/brian/xorg.conf
drwx------ 2 root root 4096 Apr 29 16:45 /home/brian/.cache/dconf
find: `/home/brian/.cache/dconf': Permission denied

And I thought I'd been very careful since installing the 64-bit system. I suspect it was incorrect usage of su & sudo which borked the first (32-bit) installation.

With the exception of the xorg.conf file (which I purposely set to root ownership but haven't bothered using it as I decided to make a startup script instead) these are all hidden directories so presumably not intended for user manipulstion.

As far as I'm aware I haven't modified any of these, or even looked at most of them!

[eatenimpinia]

Ditto for the being careful, here. I'm almost positive I didn't mess up with the sudo/gksudo thing on this installation, and I'm even more certain I didn't mess with the directories/folders that had the wrong ownership.

[Flemur]

BG405

these are all hidden directories so presumably not intended for user manipulstion.

You probably use the nautilus files - I'd make me (me meaning you) be the owner - tho you might not notice that root owns them until you try to change a setting in nautilus.

"Hidden" usually just means that you don't generally dick with them with a text editor or some such, but your programs, e.g. nautilus, still use and may change them.

I had a $HOME/.rpmdb show up after sudo-ing, I think, some rpm command to get a wifi driver installed (not needed with newer kernel); I just deleted that directory and its contents when I noticed it was there. No issues.

[BG405]

BG405

these are all hidden directories so presumably not intended for user manipulstion.

You probably use the nautilus files - I'd make me (me meaning you) be the owner - tho you might not notice that root owns them until you try to change a setting in nautilus.

You are right. I did note the modification dates and it's clear from this that my altering of the owner of the xorg.conf file wasn't the cause. But if doing stuff in Nautilus can cause this I'll certainly keep an eye on it. I'll see if I can find when I installed Nautilus; I suspect that will be quite revealing. Thanks very much for your response.

[eatenimpinia]

From what I've read, I think the Nautilus stuff you're seeing is caused by starting Nautilus, itself, with sudo (or su). Anything you saved that way (I believe) gets owned by root. But, more importantly, if your Nautilus configuration files got saved, they'd do so with root ownership. That looks like what happened.

[eatenimpinia]

I just installed Linux Mint 18 Cinnamon X32 on an old laptop. After configuring it, I decided to check the ownership of things in that computer's home folder. I got the same root ownership of the .cache/dconf folder that I got on my own machine. I'm absolutely positive I didn't mess up with sudo vs gksudo. Going through Terminal's history, all I did was:

Code: Select all

sudo wfw enable
sudo ufw status verbose
sudo sed -i 's/false/true/g' /etc/apt/apt.conf.d/00recommends
cat /proc/sys/vm/swappiness
sudo apt-get install gksu leafpad
gksudo leafpad /etc/sysctl.conf
cat /proc/sys/vm/swappiness
sudo mv -v /etc/polkit-1/localauthority/50-local.d/com.ubuntu.enable-hibernate.pkla /
sudo apt-get update && sudo apt-get upgrade

I wonder if this is a bug somewhere with something? Anyway, if anyone sees this thread before messing around with a clean install of Mint, it might be nice to check ownership of the home folder before doing anything at all.

[austin.texas]

I just installed Linux Mint 18 Cinnamon X32 on an old laptop. After configuring it, I decided to check the ownership of things in that computer's home folder. I got the same root ownership of the .cache/dconf folder that I got on my own machine. I'm absolutely positive I didn't mess up with sudo vs gksudo.

I wonder if this is a bug somewhere with something?

Yes, actually, it is... a bug. The .cache/dconf seems to be generated when you use the Update Manager. It should not work that way, but it does.
You should run the command to take ownership of all files and folders in your /home

[eatenimpinia]

Thanks. I've taken ownership of it. And, just for completeness, here's the bug report (by Cos-Mo: I wonder if that's Cosmo, here?):

https://github.com/linuxmint/mintupdate/issues/171 (oops! wrong issue, see Cosmo's link, below)

EDIT: I wonder if this is the reason I kept losing my custom Desktop when I had Mint 18 on this computer? That was one of the reasons I went back to 17.3 (the big reason was that it kept refusing to see my wired Ethernet). I wish I had checked for ownership in my home folder back then.

[Cosmo.]

,here's the bug report (by Cos-Mo: I wonder if that's Cosmo, here?),

Yes, it is me. (Cos-mo, btw, no capital m)
You linked the wrong issue. The correct links is https://github.com/linuxmint/mintupdate/issues/169

What I can see until now is, that as long as the folder /.cache/dconf and it content file user exist and the ownership has been corrected, this seems to stay with this. So no problem in the conjunction of wrong ownership seem to happen. In case you should delete the subfolder, it will be recreated at the next time, the update manager gets refreshed, so you have to correct the ownership again.

In another test system I have left the wrong ownership in the hope to find out, which consequences might follow; until now without a noticeable result.
I am interested to read, if somebody has a suspicion, so I can try to reproduce the problem and find out, if there is a relationship. Did you report the issue with the custom desktop? In this case please provide a link to that.

[eatenimpinia]

Sorry about the bad link, earlier. I've edited my post to refer to yours.

I didn't start my own thread on issues with my Mint 18 Desktop. I basically, just kept a lookout for other threads that mentioned similar problems. For instance:

viewtopic.php?f=208&t=224949

But, you've already responded in that thread. I don't think I've ever seen a definitive tie-in between the /.cache/dconf folder having the wrong ownership and the Desktop resetting.

Well, maybe there is a more definitive link:

viewtopic.php?f=208&t=228152