In Ubuntu 19.10 and later, the admonition in that article (and in this answer) no longer applies. See WinEunuuchs2Unix's answer as well as this question.
Graphical applications often store settings and other user-specific data in configuration files written inside the user's home folder. The main mechanism applications use to determine what they should use as the user's home folder is the
HOME environment variable. (You can inspect it yourself with
Suppose you're running
gedit (a graphical text editor) as
root. If you run
HOME will continue to point toward your home directory, even though the program is running as
gedit will write configuration files as
root into your home directory. This will sometimes result in the configuration files being owned by
root and thus inaccessible to you (when you later run the program as yourself and not as
root). This mainly happens when the application has to create a new configuration file. Newly created files, by default, are owned by the user who creates them (who in this case is
root, not you).
That's the primary reason why you should run graphical applications with a graphical
sudo frontend rather than with straight
sudo. In Ubuntu and most of its derivatives (including Xubuntu and Lubuntu), the standard graphical frontend is
gksudo. In Kubuntu it is
kdesudo. (It depends on the desktop environment being used.)
If you want to use
sudo directly to run a graphical application like
gedit, you can run:
sudo -H gedit
-H flag makes
HOME to point to
root's home folder (which is
That still won't automatically handle the ownership of
.Xauthority by copying it to a temp folder (this is the other thing that graphical
sudo frontends take care of for you). But in the infrequent event that
.Xauthority is inaccessible, you'll get an error saying it is, and then you can fix the problem by deleting it (
sudo rm ~/.Xauthority), as it's automatically regenerated. Thus, protecting
.Xauthority's ownership and permissions is less important than protecting the ownership and permissions of configuration files.
In contrast to a
.Xauthority, when configuration files become owned as
root, it's not always as obvious what the problem is (because graphical programs will often run, but not work very well, and output any useful errors to the console). And it's sometimes a bigger hassle to fix, especially if you're in a situation where you want one or more files in your home directory to be owned by someone other than you (because then you cannot fix it simply by recursively
chowning all your files back to yourself).
sudo (at least without
-H) should not be used to run a graphical application unless you are highly familiar with the app's inner workings and know for sure that it does not ever attempt to write any configuration files.