I think that saving it in memory can be potentially
exploited and is
something that shouldn't be done.
kdesud is protected against ptrace, at least in KDE 4.5. So I think the issue is whether we can trust the Linux kernel's memory protection. Also, KDE 4.5's "Keep password" feature (which is available in Slackware KDE packages) doesn't allow to re-use the password for another command, but only for the already launched application.
Yes, I mentioned that in my previous reply: the password is maintained only for one app, only for the current session, and only for the duratation specified in defaults.h. Not enabling the check box means the password must be re-entered for the same app, which is the same as the check box being disabled or invisible. Using kdesu with another app means retyping the password.
Then it is probably secured enough if implemented that way. Any idea of the situation in Trinity?
I can't imagine any changes from KDE3. Is there a way to test?
The fact that the option has been available for many years and still exists in KDE4 implies the feature is secure. Some distro maintainers disabled the check box, which is why many users never have seen the option, but the option has been available for many years from the untouched upstream KDE sources.
The kdesu --help options reveal that the check box can be disabled by using the -n parameter. Perhaps a desktop file could be created that specifies the default. Admins and end-users can override that default by editing the desktop file or copying the desktop file to their $KDEDIRS location and editing there. The underlying code would have to be revised to query that desktop file. That approach might be easier than creating a KControl option. Even in KControl, the default setting needs to be saved somewhere.
Darrell
So at it's core this is really a documentation issue. If the dialog box contained a single line stating the application the password is stored for and when the password storage will expire then I would be willing to add the checkbox back. Poorly defined or unknown/obscure behaviour is not a good thing when dealing with root access ;-)
Tim