| Summary: | [kdesktop] SAK driven secure dialog is not available for use | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdebase | Assignee: | Michele Calgaro <michele.calgaro> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bugwatch, darrella, gamrat.kristopher, michele.calgaro, slavek.banko, trin |
| Priority: | P3 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Other | ||
| See Also: |
http://bugs.pearsoncomputing.net/show_bug.cgi?id=2560 http://bugs.pearsoncomputing.net/show_bug.cgi?id=2945 |
||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | 898 | ||
| Bug Blocks: | 3010 | ||
The following likely all are related: 884 tdmctl: Cannot connect socket '/var/run/xdmctl/dmctl-:0/socket' 898 tsak process taking 90-100% of CPU 906 SAK realization is mostly buggy for KDM 925 [kdesktop] SAK driven secure dialog is not available for use This bug still affects R14 and 3513-sru. The names of tdmtsak and kdmtsak are correct in each of the respective releases, but with kdmrc UseSAK=true, you get the following error in ~/.xsession-errors: [kdesktop] SAK driven secure dialog is not available for use (retcode 6). Check tdmtsak for proper functionality. Further in both R14 and 3513-sru, I have had the "Press Ctrl+Alt+Del to Continue" window flash by before the loading of the old xdg greeter and never be seen by the user except if staring at the screen when runlevel 5 is initialized. It is almost like is (pops-under) the xdg greeter. Very confusing stuff... Darrell, David, is this bug still valid? Probably still valid, although for me to test is a lengthy process. Long ago I stopped compiling TDE with SAK support. That was my personal work-around to bug reports that were ignored. I would have to rebuild with that support enabled. Then I would have to try to remember after two years exactly how to recreate. Yes, this bug report remains valid. Rebuilding tdebase with SAK support I again see the reported message, despite having useSAK=false in tdmrc (kcontrol->System Administration->Login Manager->Enable Secure Attention Key). As before, I am starting X from the command line with startx. I am not using TDM. The SAK feature is meaningless when starting X from the command line. The message appears when starting with TDM. I somewhat expect the message when starting X with TDM --- although I still believe the message is nuisance spew. The message appears when using KDM rather than TDM, which, like starting X from the command line, is meaningless. Minimally the message should not appear at all when starting X from the command line or more precisely, not using TDM. Ideally just delete the nuisance spew. Users don't need the clutter in their xsession-error log and don't care whether SAK is enabled or available. Only administrators care and they know whether SAK is enabled and how to enable. By the way, I have no idea what tdmtsak might be in the message. All I find is tdmrc. I am seeing this on CentOS 6, and I am using TDM as my login manager (not KDM, command line terminals, etc.). Further, I can't enable SAK because the options to do so in the Login Manager and Screen Saver settings are "greyed out" and won't respond to mouse clicks. Kris, with reference to comment 6, can you let us know if you still see this problem. I am considering adding this bug to R14.0.5 or R14.0.6 bug list. Added to R14.0.6 bug list anyway (In reply to Michele Calgaro from comment #7) > Kris, with reference to comment 6, can you let us know if you still see this > problem. I am considering adding this bug to R14.0.5 or R14.0.6 bug list. Sometimes I see this issue, sometimes I don't. I've noticed that whenever it changes (either I can enable SAK, or I can't), it seems to be after I've added or removed some packages then rebooted. That leads me to think it's a missing dependency, most likely one of the Python ones as far as I can tell (though I'm not 100% certain on that one -- I've never been able to pinpoint exactly what package does it). I can also add both Debian Jessie and Devuan Jessie to the list of distros I've seen it on. Thanks for the update Kris. Fix available on TGW. Will be merged after the release of R14.0.6. https://mirror.git.trinitydesktop.org/gitea/TDE/tdebase/pulls/30, commit 3c109e3d10 Woohoo! 12-days shy of 7-years :) Good job all. Fix merged into main code. |
Recently the following error message appeared in my xsession log: [kdesktop] SAK driven secure dialog is not available for use (retcode %d). Check tdmtsak for proper functionality. At that time I was troubleshooting a bug with tdeinit_phase1. I had added the --lock parameter to the twin startup options. I start X/TDE from the command line with startx. TDM is not running then. When Trinity is started in that manner tsak is not available. Hence the message. However, the error message should be accompanied by more robust error checking (lockeng.cc). That is, the error should be not appear at all when Trinity is started from the command line. Or the message should be worded differently, one message when Trinity is started from TDM and another when started from the command line. if ((retcode != 0) && (mSAKProcess->normalExit())) { trinity_lockeng_sak_available = FALSE; if (tdm) { printf("[kdesktop] SAK driven secure dialog is not available for use (retcode %d). Check tdmtsak for proper functionality.\n", retcode); fflush(stdout); } else { printf("[kdesktop] The --lock parameter was passed to twin but SAK driven secure dialog is available for use only when Trinity is started with TDM (retcode %d).\n", retcode); fflush(stdout); } } Resolving this misleading error message is similar to that reported in bug report 884.