Re: [trinity-devel] First report: TSAK/TDM related issues

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