The program you execute will run under the root user id and will generally
have no authority to access your X display. KDE su gets around this by adding
an authentication cookie for your display to a temporary .Xauthority
file.
After the command exits, this file is removed.
If you don't use X cookies, you are on your own. KDE su will detect and will not add a cookie but you will have to make sure that root is allowed to access to your display.
KDE su executes the specified command by doing a su -c ". script_file"
. The
script is a temporary file and is generated by the program. Depending on the
configuration, it will look something like this:
#! /bin/sh rm -f -- {script temporary file} exec 1>{tty} 2>{tty} PATH={path when kdesu(d) was started} export PATH DISPLAY={display when kdesu(d) was started} export DISPLAY XAUTHORITY={temporary file} export XAUTHORITY xauth add {display} {cookie} 2>/dev/null {command} rm -f -- {xauthority temporary file}
KDE su will check the password you entered and gives an error message if
it is not correct. The checking is done by executing a test program: /bin/true
.
If this succeeds, the passwords is correct.
For your comfort, KDE su implements a "keep password" feature. If you are interested in security, you should read this paragraph.
Allowing KDE su to remember passwords opens up a (small) security hole in your system. Obviously, KDE su does not allow anybody but your user id to use the passwords, but, if done without caution, this would lowers root's security level to that of a normal user (you). A hacker who breaks into your account, would get root access. KDE su tries to prevent this. The security scheme it uses is, in my opinion at least, reasonably safe and is explained here.
KDE su uses a daemon, called kdesud. The daemon listens to a UNIX socket in /tmp for commands. The mode of the socket is 0600 so that only your user id can connect to it. If password keeping is enabled, KDE su executes commands through this daemon. It writes the command and root's password to the socket and the daemon executes the command using "su". After this, the command and the password are not thrown away. Instead, they are kept for a specified amount of time. This is the timeout value from in the control module. If another request for the same command is coming within this time period, the client does not have to supply the password. To keep hackers who broke into your account from stealing passwords from the daemon (for example, by attaching a debugger), the daemon is installed set-group-id nogroup. This should prevent all normal users (including you) from getting passwords from the kdesud process. Also, the daemon sets the DISPLAY environment variable to the value it had when it was started. The only thing a hacker can do is execute an application to your display.
One weak spot in this scheme is that the programs you execute are probably not written with security in mind (like setuid root programs). This means that they might have buffer overruns or other problems and a hacker could exploit those.
The use of the password keeping feature is a tradeoff between security and comfort. I encourage you to think it over and decide for yourself if you want to use it or not.