> > 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