I did not explain myself well. After I loaded uinput and set useSAK=true the check box was not showing enabled. The check box did not show the correct status thereafter. The check box was always showing disabled, contrary to useSAK=true and uinput=loaded. Everything was working as I described, just the check box did not show the correct status. I expect the check box to be ghosted when uinput is not loaded regardless of the status of useSAK, along with the warning message, and that all works. I had not thought about that either. I suppose in any environment where sak was deemed necessary, there would be training that the dialog should always appear and when that does not happen to report to an admin. In such an environment, I doubt a single console would be open to have such access as I have on mine. If SSH was available in that environment then likely keys and passphrases both would be used, so pretty tough to hack tsak. Ignoring those oddball corner cases then means tsak is working as intended. Ok, forget that. The check box needs to reflect the correct status after everything is enabled. Otherwise this patch is in the bag. Darrell

Hmm. Sorry, the patch did not work. :( useSAK=true and uinput loaded. TSAK is working as expected. The only glitch is the KControl check box does not reflect the true status, as shown in this screen grab: http://humanreadable.nfshost.com/trinity/build_logs/tsak.png Darrell

Bug fixed in GIT hash 06adb18. Sometimes it is better to look at things in the morning instead of late at night. ;-) Tim

On Monday 23 of April 2012 01:49:59 Timothy Pearson wrote: Hmm, well I should go to sleep ... and I almost backporting the patch also made ​​a mistake. (Specifically - tdm forgot to change to kdm.) :) Slavek --

This is debug spew from kdesktop and should be ignored unless you are trying to debug the Secure Dialog/Desktop Lock system. The best way to fix this is probably to make the printf() into a kdDebug so that it does not pollute .xsession_errors. Thoughts? IIRC "list" forces tdm to list all active sessions. It may be undocumented, but is used internally in the code. This is due to twin as I mentioned earlier. In order to provide a managed window environment for TDM twin has to be launched, and twin expects to see DCOP running, so it is launched as well. The "profile directory" created consists of a number of DCOP sockets and related files. I do not yet know what the best way to deal with this is. I have also repaired the desktop lock in GIT hash 50739c9--you should no longer have the desktop and icon problems you were experiencing earlier. If they do persist please let me know! Tim

After rebuilding this took a long while to test because I could not discover any repeatable patterns. Because of that, the testing was confusing. Here is what happens on my desktop with the latest patches. ============================================ When in graphical login mode and TSAK enabled: * Pressing Ctrl-Alt-Delete causes a Secure Desktop Area dialog to appear. Because of the nature of the process I could not grab a screen image. Here is an image with my digital camera: http://humanreadable.nfshost.com/trinity/build_logs/tde-lock-4.png * The Switch User and Logoff Menu buttons are ghosted/disabled. I don't know how to enable or why they are disabled. * When I tested as root, the image shows that no user ID is listed as who has the session locked. Perhaps that is intentional, but looks unprofessional. If the intent is to hide that root is logged in then the absence of a user name is a clue anyway. * Selecting the "Lock Session" button, and proceeding through the process of restoring the desktop, still causes the desktop icons to disappear, the desktop context menu to stop functioning. * Contrary to my previous report, I can log out. The process requires about 30 seconds or more to unfold, which is why I did not notice previously --- I did not wait that long. * The disappearing acts are not repeatable. Sometimes the session restored with no ill effects. * Selecting the Task Manager or Cancel buttons always cause the same ill effects. I never got the session to restore normally after using either button. * The desktop remains usable. I can still use the panel icons, TDE menu, shortcuts, etc. * For the first time I witnessed the CPU hogging reported by others. I saw this hogging only once when I invoked the Secure Desktop Area dialog. The moment I invoked the dialog by selecting the "Lock Session" button, the mouse pointer turned to an hourglass and my conky CPU usage ramped to about 68% while the frequency ramped from idle to full speed. * The CPU hogging is not repeatable. I saw the behavior only once. * Selecting the Lock applet icon works differently: causing the TSAK Ctrl-Alt-Delete dialog to appear immediately. I found this inconsistent and therefore confusing. I would have thought the Lock icon would invoke the "Secure Desktop Area" dialog. * Using the Lock applet icon results in the same loss of functionality. * I preset my screen saver to 1 minute and while in Lock Session mode the screen saver activated as expected. ============================================ When in graphical login mode and TSAK disabled (useSAK=false, uinput not loaded): * Pressing Ctrl-Alt-Delete exits the session to TDM. * In this mode the only method to lock the desktop is to use the Lock applet icon (or shortcut). Unlike KDE3, selecting the Lock applet icon does not cause the screen saver to immediately activate. Instead, a "Desktop Session Locked" dialog appears immediately. The screen saver does not activate until the expected setting timeout. Image: http://humanreadable.nfshost.com/trinity/build_logs/tde-unlock-4.png * Same ill effects and I can log out but the logout process takes a long time, about 30 seconds. * The Cancel button is always ghosted. * I am not able to again to lock the session. * There are a bunch of dcop socket files in /tmp/.ICE-unix. ============================================ When in command line login mode: * Pressing Ctrl-Alt-Delete exits the session to the command line. * In this mode the only method to lock the desktop is to use the Lock applet icon (or shortcut). Unlike KDE3, selecting the Lock applet icon does not cause the screen saver to immediately activate. Instead a "Desktop Session Locked" dialog appears immediately. The screen saver does not activate until the expected setting timeout. Image: http://humanreadable.nfshost.com/trinity/build_logs/tde-unlock-3.png * The "Desktop Session Locked" dialog Cancel button is ghosted/disabled. * Typing my password restores the desktop, but: * Just before the "Desktop Session Locked" dialog appears, sometimes I momentarily saw the TSAK Ctrl-Alt-Delete dialog. * tdmrc:useSAK=false during these tests. Besides, this is command line mode, and TSAK should never be involved. * Most often upon restoring the desktop, like before, desktop icons disappeared, the desktop context menu ceased to function. * Occasionally, when the desktop icons did not disappear and the desktop context menu still functioned, before returning to the desktop I was always presented with the "Desktop Session Locked" dialog multiple times. Sometimes the dialog reappeared only once, but sometimes more often. * I can log out but the logout process takes a long time, about 30 seconds. * Always I am not able to again to lock the session. ============================================ With both the graphical login mode with TSAK disabled and command line login: * Sometimes two pipe files in appeared /tmp/tdesocket-global: kdesktoplockcontrol and kdesktoplockcontrol_out. They do not disappear when the screen is unlocked. Looks like some more housekeeping needed. * The two pipe files did not always appear. I don't know the pattern to repeat. * Seems to me that in these two modes, when TSAK should be out of the picture (but possibly inadvertently isn't), the process should work exactly the same as in KDE3, except with different dialogs: screen saver and then dialog. * The Cancel button in all dialogs should be enabled all the time. ============================================ Overall, I am unable to discern patterns to repeat the events I am sharing. Hence the ugly report. Let me know what further testing you want or need. Testing this locking mechanism is one of the more time consuming tests because of the weird events, which require restarting the session because only one lock is allowed and then the feature stops working. Darrell

The steps to replicate the desktop icon problem are: 1.) Set the screen saver interval to something short like 1 minute 2.) Wait for screen saver to activate 3.) Move mouse. Viola, icons are now gone. Working on this... Tim

You probably have your system configured with a lock delay, correct? The issue seems to be in the code that is triggered before the screen is actually locked with a password. Tim

Some additional information: one symptom of this problem is kdesktop_lock not exiting properly and going zombie, e.g. ps aux | grep kdesktop_lock shows something like user <pid> 1.1 0.0 0 0 ? Z 14:45 0:00 [kdesktop_lock] <defunct> This indicates a problem in kdesktop itself. Tim

I tested again with the latest patch for a race condition. The patch has stabilized just about everything. :) No more desktop icon disappearance. The desktop context menu works. Alt-F2 works. I can logout using any option. No misbehavior when selecting the Task Manager or Cancel buttons. Comments: * I still notice the tsak Ctrl-Alt-Delete dialog appearing momentarily before the Desktop Session Locked dialog appears. I think a slower system is needed to see this, like a VM, because I can't see the dialog when running on my regular hardware. I doubt the dialog appearing is good or intentional. Especially when I see the dialog in command line login mode, which means tsak is not supposed to be in the picture at all. Not to mention that appearing momentarily like that does not look "high quality." :) * All dialogs appear before the screen saver. I don't know that this is incorrect or bad, but is the opposite behavior of KDE3 and will require long-time users time to grow accustomed. * For years I have used Ctrl-Alt-Delete as my logout shortcut. That shortcut works except when useSAK=true. The missing element is the Logout button is ghosted/disabled in the dialog. You mentioned that the feature has not been implemented, but seeing that feature added will be nice. :) * As mentioned previously, the Secure Desktop Area dialog does not show root's account name in the dialog. Just the single quotation marks with nothing in between. * When the Secure Desktop Area dialog appears, and after selecting the Lock Session button, the mouse pointer turns to an hour glass. I think many users will find that confusing. That "busy" mouse pointer indicates something is going to happen, that the system is busy doing something. The inclination for the user is to wait for the "busy" condition to dissipate because that is what users are accustomed to doing. Yet nothing ever happens until the user bumps the mouse or presses a keyboard key. The busy pointer doesn't feel right. Perhaps instead of the busy pointer, the screen saver should activate immediately. Immediately activating the screen saver also provides feedback that the system is locked because that is how the process functioned in KDE3 and other desktops. * I have not yet seen the CPU hogging issue return but others who witnessed that mystery will have to test further. I saw that happen only once. Good job with the patch! Darrell

Another symptom of this bug: Alt-F2 will not launch the minicli and I can't run the minicli from the TDE menu. I noticed the most recent patch addressing a race condition. I am rebuilding and will test again. For now: xsession log output (ignoring standard messages): ======================================================= graphical login, useSAK=true, uinput loaded, pressing Ctrl-Alt-Delete: Couldn't get a file descriptor referring to the console WARNING: DCOPReply<>: cast to 'TQStringList' error WARNING: DCOPReply<>: cast to 'TQString' error [twin] X_SetInputFocus(0xe00017): BadMatch (invalid parameter attributes) ======================================================= graphical login, useSAK=true, uinput loaded, selecting the Lock applet icon: Couldn't get a file descriptor referring to the console WARNING: DCOPReply<>: cast to 'TQStringList' error WARNING: DCOPReply<>: cast to 'TQString' error ======================================================= graphical login, useSAK=false, uinput not loaded, selecting the Lock applet icon: WARNING: DCOPReply<>: cast to 'TQStringList' error WARNING: DCOPReply<>: cast to 'TQString' error ======================================================= command line login, useSAK=false, uinput not loaded, selecting the Lock applet icon: WARNING: DCOPReply<>: cast to 'TQStringList' error WARNING: DCOPReply<>: cast to 'TQString' error ======================================================= Darrell