Perhaps a couple of changes: * The What's This popup should provide the uinput information. * Whenever a user enables the SAK check box in KControl, upon pressing the Apply button the code should determine whether uinput is loaded. If not, provide an informational OK dialog that uinput needs to be loaded. If uinput is loaded then don't bother with a dialog. BTW, the help handbook has nothing about TSAK. Nada. :) Back to our regularly scheduled testing. ================================================================ With tdmrc:useSAK=true and booting into graphical login mode: * I am presented with the Ctrl-Alt-Del dialog. * I am able to proceed past the Ctrl-Alt-Dialog to the login dialog. * I see two pipe files in /tmp/tdesocket-global: 1) tsak and 2) tsak.lock. Permissions of both are 600, root:root. * /tmp/tdesocket-global is owned by root:root and not the primary user account. * After logging in and upon pressing Ctrl-Alt-Del I am presented with a TSAK Lock Session dialog. Things got buggy here. When I selected Cancel I lost all of my desktop icons, the desktop context menu would not appear, and thereafter trying to logout using any option or press Ctrl-Alt-Del did nothing. I had to press Ctrl-Alt-Backspace and login again. Note: I use Ctrl-Alt-Del as my shortcut to logout. I also logout using the desktop popup menu, the TDE Menu, and the Logout applet. I use all four methods --- no predicting which one I might use. The TSAK Lock Session dialog appears only when pressing Ctrl-Alt-Del and does not appear with the other methods. Perhaps intended, but this seems inconsistent and confusing. Should users see the TSAK logout dialog using all methods to logout? * Upon pressing Ctrl-Alt-Del and being presented with the TSAK Lock Session dialog, selecting Lock Session works, but again the desktop icons disappear, the desktop context menu would not appear, and I could not logout thereafter. * Using the Lock session applet button worked but resulted in the same loss of desktop icons when the session was restored. Same result too that I had to press Ctrl-Alt-Backspace to recover. * I am not sure the disappearance of the desktop icons and desktop context menu and inability to logout is directly caused by the TSAK Lock Session dialog. Several times when testing this happened anyway although I did not call the TSAK Lock Session dialog. Certainly related to TSAK because when TSAK is disabled the problem evaporates. * Upon logging out, after pressing Ctrl-Alt-Del to obtain access to the TDM login dialog, I reset the X server using the Alt-E shortcut. The file date stamp on /tmp/tdesocket-global/tsak changed to that time but the tsak.lock file retained the time stamp from my boot time. That means restarting the X server only partially resets TSAK. * Disabling TSAK from KControl does not immediately stop TSAK. After disabling through KControl, immediately pressing Ctrl-Alt-Del invokes the TSAK Lock Session dialog with all of the same results of losing desktop icons and needing to press Ctrl-Alt-Backspace. This seems inconsistent. My thinking is when I disable TSAK in KControl then I have done just that: disabled. If disabling TSAK requires something additional, such as resetting the X server or rebooting, then a popup dialog should inform the user that the change won't take effect until that condition is satisfied. * After disabling TSAK in KControl, upon returning to the TDM dialog, I was not presented with a Ctrl-Alt-Del dialog. I reset the X-server anyway. Upon logging in, the tsak.lock pipe file remained and was not deleted. * After disabling TSAK in KControl, I could not use Ctrl-Alt-Del to logout. That won't do. :) I suspect there is a relationship with uinput. * After disabling TSAK in KControl, rebooting, and not loading uinput, I then could again use Ctrl-Alt-Del to logout. * I am not allowed to rmmod uinput without rebooting or changing run levels. Disabling TSAK through KControl and restarting the X server is insufficient. * After rebooting, the tsak.lock pipe file remains. No housekeeping. The file should get deleted at the same time the tsak pipe file is deleted. ================================================================ With tdmrc:useSAK=true, booting into command line, using startx: * I cleaned /tmp before rebooting. * I did not load uinput. * I could use Ctrl-Alt-Del to logout. * There were no tsak pipe files to be found. * The xsession message "[kdesktop] SAK driven secure dialog is not available for use (retcode 6). Check tdmtsak for proper functionality." still appears. * The xsession message "tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket'" still appears. ================================================================ Note: I have yet to file a bug report but TDM creates nominal profile directories in /tmp. All such directories use a numeric name string. TDM runs as non-user, but should not be creating any profile directories. Not needed and the profile directories are never purged. This never happened in KDE3. With my testing, which required many repeated logins, my /tmp directory was overflowing with these (useless) profile directories. Some distros have built-in cleanup scripts on shutdown. some don't. As this profile creation never happened in KDE3, we should look into why this now happens in TDE. ================================================================ Summary: Lots of details here, initially looks overwhelming, but good progress overall. Mostly this narrows to a few issues. * Adding informational aides about uinput. * What is happening with the TSAK Lock Session dialog with why the desktop icons disappear, the desktop context menu will not appear, and the user can't logout thereafter. * Remove the two xsession messages when logging in from the command line. * Improve housekeeping by removing tsak.lock: 1) upon a reboot (TDM should do this), 2) disabling TSAK from KControl. * I do not recommend automatically loading uinput for the user because with the next reboot the module again needs to be loaded. The distros all differ with how that is accomplished. Possibly a nice aide would be whenever the system starts and TDM detects the status of useSAK=true, and uinput is not loaded, perhaps an informational "OK" dialog appears informing the user. The uinput requirement is just not obvious anywhere. Darrell

OK, sounds reasonable, though I would rather disable the TSAK checkbox and display a warning message next to it, in order to provide more immediate feedback as to the state of the user's system. Probably because I still have not figured out how to use the docbook stuff, nor do I have plans to do so. :-) <snip> I'll start working on these ASAP... Thanks for the detailed report! Tim

I got bitten by this myself, but as I was running tsak from the command line at the time the problem was obvious. I can't imagine how frustrating it would have been from within a GUI... TSAK stands for Trinity Secure Attention Key. A Secure Attention Key is a special keypress to which only certain privileged applications, such as the login and unlock dialogs, are able to respond. This prevents an ordinary user from creating an exact copy of the login screen to "sniff" passwords or other sensitive information, as the unprivileged copy will not be able to detect the SAK keypress, thus providing a visible difference in operation to the user. Generally, using TSAK is a good idea when you have more than one graphical login account on a machine, for instance in enterprise environments or computer laboratories. If you have only one graphical login account TSAK will not provide tangible benefits over the standard login methods. TSAK requires udev and uinput. When TSAK is in use, you will be prompted to press Ctrl+Alt+Del before sensitive information is requested. If TSAK is enabled on a system, and you do not see the Ctrl+Alt+Del dialog before sensitive information is requested, someone may be attempting to phish for that information. The most prudent course of action would be to terminate the active X11 session via Ctrl+Alt+Backspace or any other distribution-specific keypress for this action, this restoring control to the kernel and base system. Tim

On Thursday 19 April 2012 19:23:41 Timothy Pearson wrote: just a note for anyone interested in working on docbook stuff: quanta+ is great for that, there is also a tutorial: http://web.archive.org/web/20071217070232/http://quanta.kdewebdev.org/tutor… (now in web archive as kdewebdev.org seems no longer to exist) Werner

On Thursday 19 April 2012 20:19:56 Darrell Anderson wrote: sure. in addition, quanta can be easily expanded via kommander scripts, which can directly work on the actual content. not much, I used it once for docbook editing in 2004, IIRC. (forgot the most since then, I must admit..) great. would be a pity to loose them (more or less, as is the current state). Werner