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