<snip>
> Summary:
>
>  * Glitch: KControl is not displaying the check box as enabled despite
> useSAK=true. Probably a forgotten or misplaced readEntry?

This behaves that way on purpose--when useSAK=true and tsak cannot be
enabled (i.e. when uinput is not loaded) the checkbox is not checked to
avoid the appearance of tsak being permanently enabled.  If this is
confusing then we will need to find a better way to indicate this.

>  * Possible glitch: Seems TDM should restart tsak as soon as I logged in,
> despite my "malevolent" effort to disable tsak. However, as shown by the
> Switch User test, TDM immediately restarted tsak, and that probably is
> sufficient. Within the intent of how tsak should function (I don't know
> the specs), I'm unsure whether TDM should be polling the process list to
> immediately restart tsak when disabled as I circumvented. Seems to me
> that a user should not be able to do what I did. Even if I did not have a
> free console open, I could have accomplished the same with through SSH.
> Seems to me that as long as useSAK=true tsak should be a persistent
> little b-stard. :)

I never really thought about this, but I guess this might be a correct way
of looking at it.  My original thought was that if someone killed tsak,
all users would know that the system was compromised as the Ctrl+Alt+Del
screens would not appear or function.  Automatically restarting tsak might
make more sense, but TDE's design doesn't make this particularly easy.

> The desktop lockout bug remains (desktop icons and context menu disappear,
> can't logout), and the profile directories accrue like rabbits copulating,
> but this patch did not address those issues. :)

The desktop lock seems to be rather badly messed up in general.  I need to
figure out what happened to cause this; it probably broke in my earlier
attempts to convert it to a persistent process.

Tim