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