Rebuilt with latest three tdebase patches.
I did not build tdebase with DBUILD_TSAK=OFF.
After setting tdmrc:useSAK=true using KControl and verifying tdmrc updated:
I do not see a Ctrl-Alt-Del dialog. Ever.
I do not see any pipe/socket files anywhere.
tdesocket-global is empty of any files.
tdesocket-global has root:root ownership.
I both restarted the X server and rebooted. No change. Same results as listed.
I don't know what I should see or when.
When should I see the Ctrl-Alt-Del dialog?
When and where should I see pipe/socket files?
Darrell
Rebuilt with latest three tdebase patches.
I did not build tdebase with DBUILD_TSAK=OFF.
After setting tdmrc:useSAK=true using KControl and verifying tdmrc updated:
I do not see a Ctrl-Alt-Del dialog. Ever.
I do not see any pipe/socket files anywhere.
tdesocket-global is empty of any files.
tdesocket-global has root:root ownership.
I both restarted the X server and rebooted. No change. Same results as listed.
I don't know what I should see or when.
When should I see the Ctrl-Alt-Del dialog?
When and where should I see pipe/socket files?
Darrell
You will only see the dialog if: 1.) It is turned on in tdmrc via tdmrc:useSAK=true as you stated 2.) Your system fully supports tsak; this usually means that you need to load the uinput kernel module on Linux. Trying to run /opt/trinity/bin/tsak manually (as root) will give you the exact reason for any failures encountered.
Tim
You will only see the dialog if: 1.) It is turned on in tdmrc via tdmrc:useSAK=true as you stated 2.) Your system fully supports tsak; this usually means that you need to load the uinput kernel module on Linux. Trying to run /opt/trinity/bin/tsak manually (as root) will give you the exact reason for any failures encountered.
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
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.
I am wondering if this is actually a problem with KDesktop, the desktop icons have had plenty of problems in the past and do as of 3.5.13
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.
Again, all distros handle the /tmp different, so the best way would be to check if those file exist during the startup of the computer. if it already exists, delete and create a new one.
- 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.
I mean TDM/TSAK typically starts on boot, so I see the module being loaded by TDM as fine. Xorg loads kernel modules for example, for the drivers and input if they are not there. TDM should also load neccessary modules. I don't think we need to say "Uinput loaded" in a dialog, if anything just a output to a log saying that it was loaded. All current linux systems use modprobe so I think that's fairly straight across the board.
Calvin
You will only see the dialog if: 1.) It is turned on in tdmrc via tdmrc:useSAK=true as you stated 2.) Your system fully supports tsak; this usually means that you need to load the uinput kernel module on Linux. Trying to run /opt/trinity/bin/tsak manually (as root) will give you the exact reason for any failures encountered.
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.
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.
BTW, the help handbook has nothing about TSAK. Nada. :)
Probably because I still have not figured out how to use the docbook stuff, nor do I have plans to do so. :-)
<snip>
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
I'll start working on these ASAP...
Thanks for the detailed report!
Tim
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.
That sounds better. All we need is a mechanism that makes the uinput connection obvious to the user. I never would have figured that out. Well, maybe --- after many four letter words and scouring the source code. :) A context sensitive warning directly in the KControl dialog will do nicely.
BTW, the help handbook has nothing about TSAK. Nada. :)
Probably because I still have not figured out how to use the docbook stuff, nor do I have plans to do so. :-)
Send me the text. :)
We don't need a book. Just a few paragraphs. I'll merge the text into the existing TDM help file. Basic description for now:
What is TSAK. When to configure. Requirements/dependencies. How to use/what users see.
I'll start working on these ASAP...
Thanks for the detailed report!
Par for the course. :) We're in good shape. Most of those details were exhaustive ways of describing the booginess of the Lock Session dialog. The housekeeping and xsession messages should be straightforward fixes. I'll guess with the two xsession messages that they appear once the code determines useSAK=true and can't find TDM. A simple error check routine would eliminate the messages such as whether TDM is running.
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.
That sounds better. All we need is a mechanism that makes the uinput connection obvious to the user. I never would have figured that out. Well, maybe --- after many four letter words and scouring the source code. :) A context sensitive warning directly in the KControl dialog will do nicely.
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...
BTW, the help handbook has nothing about TSAK. Nada. :)
Probably because I still have not figured out how to use the docbook stuff, nor do I have plans to do so. :-)
Send me the text. :)
We don't need a book. Just a few paragraphs. I'll merge the text into the existing TDM help file. Basic description for now:
What is TSAK.
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.
When to configure.
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.
Requirements/dependencies.
TSAK requires udev and uinput.
How to use/what users see.
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
BTW, the help handbook has nothing about TSAK.
Nada. :)
Probably because I still have not figured out how to use the docbook stuff, nor do I have plans to do so. :-)
Send me the text. :)
We don't need a book. Just a few paragraphs. I'll merge the text into the existing TDM help file. Basic description for now:
Help documentation updated in GIT hash ff0bcfcc.
* Open the help center (TDE menu->Help).
* Scroll a few lines down in the TOC.
* Select Login Manager.
Chapters 3 and 4 were updated.
Darrell
On Thursday 19 April 2012 19:23:41 Timothy Pearson wrote:
BTW, the help handbook has nothing about TSAK. Nada. :)
Probably because I still have not figured out how to use the docbook stuff, nor do I have plans to do so. :-)
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/tutori... (now in web archive as kdewebdev.org seems no longer to exist)
Werner
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/tutori... (now in web archive as kdewebdev.org seems no longer to exist)
Yes, I need/want to start using Quanta Plus more. I have been using Kate for basic editing but to write something from scratch, the built in tools with Quanta Plus would be more enticing.
Do you have experience using Quanta Plus and docbook?
By the way, I have a copy of that web page. Originally part of a trio of docbook files for writing help files for KDE3. I intend to incorporate those three docs into the Trinity help system, under Tutorials in the main help index.
Darrell
On Thursday 19 April 2012 20:19:56 Darrell Anderson wrote:
Yes, I need/want to start using Quanta Plus more. I have been using Kate for basic editing but to write something from scratch, the built in tools with Quanta Plus would be more enticing.
sure. in addition, quanta can be easily expanded via kommander scripts, which can directly work on the actual content.
Do you have experience using Quanta Plus and docbook?
not much, I used it once for docbook editing in 2004, IIRC. (forgot the most since then, I must admit..)
By the way, I have a copy of that web page. Originally part of a trio of docbook files for writing help files for KDE3. I intend to incorporate those three docs into the Trinity help system, under Tutorials in the main help index.
great. would be a pity to loose them (more or less, as is the current state).
Werner
-
Calvin Morrison -
Darrell Anderson -
Timothy Pearson -
Werner Joss