By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 1712 - Unexpected behavior when switching users through TDM
Summary: Unexpected behavior when switching users through TDM
Status: NEW
Alias: None
Product: TDE
Classification: Unclassified
Component: tdebase (show other bugs)
Version: R14.0.x [Trinity]
Hardware: Other Linux
: P5 normal
Assignee: Timothy Pearson
URL:
Depends on:
Blocks: 2968
  Show dependency tree / graph
 
Reported: 2013-11-14 16:39 CST by Darrell
Modified: 2018-08-30 02:52 CDT (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2013-11-14 16:39:59 CST 
Using a graphical login with TDM:

* Log in as User 1.
* From the TDE menu select Switch User->Start New Session.
* Log in as User 2.
* Switch to User 1: Notice no password is required.
* Switch to User 2: A password is required.
* Switch to User 1: A password is required.

Unexpected is the first instance of switching back to User 1 does not require a password and all other instances of switching require a password, regardless of the user.

There seems to be a time function associated with switching. I was not always asked for a password on subsequent switching, especially when I used the keyboard toggles of Ctrl-Alt-F7 and Ctrl-Alt-F8 and switching quickly.

SAK is disabled.

I only used Switch User->Start New Session. I did not use Switch User->Lock Current & Start New Session.

When using Switch User->Start New Session, seems the behavior should be one of the following:

* For consistency, returning to User 1 the first time should require a password.

* No passwords required at all when using 'Start New Session', that is what 'Lock Current & Start New Session' option seems to be for.
Comment 1 Timothy Pearson 2013-11-15 01:08:13 CST 
Do you have a "Lock Current & Start New Session" entry in your "Switch User" menu?
Comment 2 Darrell 2013-11-15 11:40:46 CST 
> 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.
Comment 3 Michele Calgaro 2013-11-18 06:02:33 CST 
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.
Comment 4 Darrell 2013-11-18 15:20:46 CST 
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.