| Summary: | Unexpected behavior when switching users through TDM | ||
|---|---|---|---|
| Product: | TDE | Reporter: | Darrell <darrella> |
| Component: | tdebase | Assignee: | Timothy Pearson <kb9vqf> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | bugwatch, darrella, kb9vqf, michele.calgaro |
| Priority: | P5 | ||
| Version: | R14.0.x [Trinity] | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Compiler Version: | TDE Version String: | ||
| Application Version: | Application Name: | ||
| Bug Depends on: | |||
| Bug Blocks: | 2968 | ||
|
Description
Darrell
2013-11-14 16:39:59 CST
Do you have a "Lock Current & Start New Session" entry in your "Switch User" menu? > Do you have a "Lock Current & Start New Session" entry in your
>"Switch User" menu?
Yes.
I'm not saying this is or isn't a bug. I understand the security desire for locking, but the observed behavior is unexpected. To me, either locking should occur with the first instance of returning to User 1 or locking should not occur at all for any of the users when using "Switch User->Start New Session."
My reasoning is because the "Lock Current & Start New Session" option explicitly implies locking.
I see use cases where locking is not wanted at all. For example, when I am testing, often I use special testing login accounts. I want to toggle back and forth without delay. This example use case prompted me to open this report because I found the locking disruptive --- and annoying.
That said, perhaps there is a simple configuration option I'm not using to avoid locking.
I don't recall 3.5.10 doing this but to be fair I realize much work has gone into security and screen locking under Trinity.
In my opinion, we should try to achieve a consistent behavior. One solution would be to always lock the current session when switching to another one. This would put security in first place, but on the other hand could be annoying to users that repeatedly switch between multiple sessions. Another (better) possibility would be to remove the entry "Lock Current & Start New Session" and add a general configuration option "Lock session when switching to another one". If the option is enabled, each session switch will lock the current session; if the option is disable, the current session will never be locked. The user still has the choice of manually locking the session before switching to another one with Ctrl-Alt-F7 and Ctrl-Alt-F8 if locking is temporary required. Personally I prefer the second one, since it gives the user the possibility to adjust the configuration to his needs. Yes, consistency should be the goal. "Lock Current & Start New Session" has existed since at least 3.5.10. I don't think we should remove that menu option because there is too much user familiarity and history for such a change. I tested user switching on 3.5.10. The locking behavior is the same when selecting the "Start New Session" option. In 3.5.10, the screen saver and locking is activated for each user despite the screen saver being disabled for each user. Therefore the locking was not added in Trinity but has existed since KDE3 days. I don't have a problem with a new user configuration option for locking. As locking has existed since at least 3.5.10 when selecting the "Start New Session" option, I don't know that we can fix the problem any other way. Perhaps such an option already exists but is cleverly hidden. If we add a new configuration option (I don't know from which GUI we would configure this new option), the default behavior must be to leave the locking behavior enabled. Incidentally, none of this is a problem when starting X from the command line rather than through TDM. As I never was much of a login manager users, preferring through the years to start X from the command line, I never really appreciated this problem until recent testing for Trinity. Thus, likely I am in the minority of users because most are well accustomed to this locking behavior. I still believe there is a problem for users who want to run without locking. |