Gedit with Sudo – What Specific Bad Things Happen When Gedit is Used with Sudo?

configurationgeditownershiprootsudo

I read this answer explaining that "sometimes" root can own something at /home/$USER directory.

Can anyone give an example how to prove it. Just give a test case when something really bad happens, when I run

sudo gedit /etc/rc.local

edit file and save.

I got many downvotes trying to help OP out and comments flooded in saying that it is a crime to run gedit with sudo.

Can anyone give a real example?

I clearly explained why this question is not a duplicate. There is no answer specific to gedit to the linked question.

And it is important to explain why widely used sudo gedit is bad, or not really, etc.

Best Answer

As far as sudo gedit, nothing dire, just poor practice, especially as of late. How much harder would it be to suggest sudo -H gedit?

-H, --set-home Request that the security policy set the HOME environment variable to the home directory specified by the target user's password database entry. Depending on the policy, this may be the default behavior.

What does happen?

You get a couple of root owned files in your home folder. One (recently-used.xbel) will likely return to user ownership. This can happen when a file is deleted and re-created. To see what sudo gedit has changed, run find ~ -user root -group root and see what is returned. By default, this is should be nothing.

With that command, you may see a couple files owned by root. One would be a new .file, .gvfs, and sooner or later a root-owned ~/.cache/dconf and the aforementioned recently-used.xbel.

So no 'the sky is failing' stuff, but still. Now there have been reports that continued use causes other issues but not going to claim what I don't see here.

Also note that as of 13.10 a sudo gedit will use the user's gedit config rather than root's gedit config. Again just bad practice so why continue to do so or suggest others do so?

Related Question