As this question comes up with some frequency I've summarized the differences between gksudo/kdesudo, sudo, and su below. Based on the default sudoers configuration for Linux Mint 18.

You should generally always use gksudo (on Cinnamon/MATE/Xfce) or kdesudo (on KDE) for running graphical programs as root. Use sudo and su only for command line programs. Otherwise you may end up with the graphical programs changing ownership of files in your home directory to root, which can cause lots of issues.

gksudo, kdesudo, and sudo are authorized with your own password and you need to be a member of the sudo group to be able to use them. su requires you to authorize with the password of the user you're changing to and you don't need to be a member of the sudo group to be able to use it. For gksudo and kdesudo you get a graphical window to type your password in. For sudo and su you type the password on the terminal (which doesn't give you any visual feedback as you type it).

Summary of differences between these commands:

gksudo and kdesudo set $HOME to the home directory of root, and set $XAUTHORITY to a new file outside your home directory (though with the same cookie for communicating with the X server), so the program you run doesn't change ownership of files in your home directory to root. Only a limited number of environment variables, and no functions or aliases, are preserved when changing user this way.

sudo does neither of those and thus should generally not be used for graphical programs as these use those environment variables. Only a limited number of environment variables, and no functions or aliases, are preserved when changing user this way.

sudo -i does set $HOME to the home directory of root, and also changes to that directory, but as it doesn't set $XAUTHORITY should still not be used for graphical programs. Only a limited number of environment variables, and no functions or aliases, are preserved when changing user this way.

sudo -H does set $HOME to the home directory of root but as it doesn't set $XAUTHORITY should still not be used for graphical programs. Only a limited number of environment variables, and no functions or aliases, are preserved when changing user this way.

su does set $HOME to the home directory of root but as it doesn't set $XAUTHORITY should still not be used for graphical programs. All environment variables (with a few changes), but no functions or aliases, are preserved when changing user this way.

su - does the same thing as sudo -i (but you authorize su with root's password and sudo with your own).

(Tested by running the printenv command with each, saving the output, and comparing those with meld.)

The option -H does change the value for the variable $HOME - but this does not work for graphical programs. So even with -H option sudo does give the problem and gksudo / kdesudo have to be used for graphical programs.

The Option -H makes sense for using sudo on the command line.and should IMO always be used for that.
Even better: It is possible to configure sudo in a way, that this option gets used automatically, so you can save some key presses and cannot forget it. I don't know, why this does not get done out of the box. I do this since the beginning and have never found any problem out of this.

For changing the sudo configurtion for this, you have to have to edit /etc/sudoers wiith this command:

2 Warnings about editing this file:
At first, the file sudoers must always end with an empty line.
At second: editing this file has the risk, that the user does a mistake, which might end with the result, that the system gets unusable afterwards. For preventing you against such risk you can - before you edit the file - open a second terminal and open a root-shell with sudo -i. When you have edited and saved the file, test sudo in the first terminal. If this works, you can safely close the root-shell.

Additional tip:
As you are about to edit sudoers you can at the same time do another change: You can change the behavior for the password request in a way, that you get asterisks as a visual feedback, as you get the bullets as visual feedback in graphical requests. You can do this by inserting another new line:

sudo -H does set $HOME to the home directory of root but as it doesn't set $XAUTHORITY should still not be used for graphical programs. Only a limited number of environment variables, and no functions or aliases, are preserved when changing user this way.

I've stickied the topic and added the sudo -H part and made a few minor changes.

As for pkexec, it does set $HOME safely but as austin.texas gave the example it uses the .Xauthority file in your own home directory. The pkexec manpage makes clear that setting the $DISPLAY and $XAUTHORITY environment variables is discouraged and should only be used for legacy programs. Who wants to be the one to admit they use "legacy programs" (I'm thinking COBOL? ). I'm no expert on pkexec but I think Polkit is intended to do away with need to run an entire program as root. The manpages for those interested:https://www.freedesktop.org/software/po ... kit.8.htmlhttps://www.freedesktop.org/software/po ... xec.1.html

Not necessarily. Yes, by default gksu uses sudo as authentication method (so it behaves like gksudo), but this can be changed and consequently this is not the same on every system and not even for every user account on the same machine, as this is a per-user-setting.

You can change this either temporarily or permanent. For temporary using of su as backend you have to set the option -w (gksu -w ....).

You can change this also permanently. Enter(in a terminal or the commandline via alt-F2) gksu-properties. This gives a graphical dialog, where you can switch to su as authentication method. This makes sense IMO, as this allows to run graphical programs without sudo-membership, if you know the password of the other user. With the default setting gksudo and gksu behave the same, what appears to be a needles redundancy.

If you have done this permanent switch, you have again the possibility to temporarily using sudo as backend. The option is in this case -S.
Note (a little bit confusing): -w needs a not capitalized w, -S needs a capital S.

... gksudo is symlinked to gksu. however this does not mean they are doing a similar things, off from it.

Applications will notice the command accustomed run it. this is often generally argv[0] in C-style languages or $0 in Bourne-style shell scripts. the applying will look into that and during this case, truly it changes however it works. the primary indication of this is often within the man gksu page:

gksu is a frontend to su and gksudo could be a frontend to sudo.

If you look within the supply (apt-get supply gksu) for run_mode, you will see however it detects this:

run_mode = SUDO_MODE;
g_free (myname);
">

You can override this with the --su-mode/-w and --sudo-mode/-S arguments (so you'll run equivalent commands without having the gksudo symlink... however that is up to you.

If you would like to grasp however these "modes" very dissent, there is solely a small amount of escaping in gksu. you wish to follow it into libgksu. this is often the library that really checks permissions before handing off to the system.

If no mode is nominal (eg you decision gksu while not arguments) by the time it reaches libgksu, it'll check Gconf (as Stefano points out) and if it still cannot decide, it will default to the su mode.