GNOME Bugzilla – Bug 698647
non-obvious interactions between enabling/disabling accounts and auto-login
Last modified: 2013-06-05 16:15:39 UTC
Steps: * Have an account with a password, with automatic login enabled * Unlock Users panel * Click on Password entry * Action: Disable this Account * Change Expected result: Automatic Login also disabled Actual result: Automatic Login remains enabled, but the switch is insensitive, so it cannot be disabled Another, similar situation: * Have an account with disabled password, with automatic login disabled * Unlock Users panel Expected result: Automatic Login switch is off and insensitive Actual result: Automatic Login switch is off, but sensitive; when Automatic Login is enabled, the account logs in automatically, despite having a disabled password --- It's arguable whether these "expected results" should be expected or not, but I've seen bug reports (non-public, unfortunately) saying that they're what should have happened; so either the bug reporter is right, or the terms used in gnome-control-center aren't setting up the right expectations. I do understand why this happens, behind the scenes - "account disabled" just means "the password is set to something that can never be matched", whereas gdm's automatic login mode bypasses password-checking completely - but I can also see that from the point of view of a user who doesn't know the details of Unix passwords, it isn't at all obvious why a "disabled" account can still auto-log-in. One possible resolution would be for disabling an account through the g-c-c UI to disable automatic login as a side-effect, and for the "Automatic Login" switch to be insensitive for disabled accounts. (Obscure corner case: perhaps it should be insensitive unless it was initially on, so that users who have set up the "inconsistent" situation via configuration file editing can turn it off, and can undo turning it off.) Another possible resolution would be "this is not a bug, the reporter is just confused" (with or without adjustments to the wording used in g-c-c). In principle, gdm could refuse to auto-log-in a disabled account, but I don't think that's really particularly useful: only root can set up this situation, so it isn't a security flaw or anything. It certainly doesn't seem right that "disabling" an auto-logging-in account results in the switch being on, but insensitive: either it should become off and insensitive, or it should remain on and sensitive.
Created attachment 242279 [details] [review] [1/2] Turn off auto-login when an account is locked It seems reasonable to expect that an operation labelled "Disable this account" will prevent it from becoming logged-in, even automatically.
Created attachment 242280 [details] [review] [2/2] Disallow enabling auto-login for locked accounts, but allow disabling it The allowed state transitions are: unlocked, auto-login <-> unlocked, no auto-login unlocked, auto-login -> \ unlocked, no auto-login -> } locked, no auto-login locked, auto-login -> / After making the transition from the confusing state (L,AL) to (L,NAL) you can also undo it, but only for as long as the same user is selected.
(In reply to comment #0) > Another possible resolution would be "this is not a bug, the reporter is just > confused" (with or without adjustments to the wording used in g-c-c). If this is the desired resolution, then the auto-login slider shouldn't be made insensitive for locked accounts.
Thank you for your bugreport. This'll be fixed with Bug 695450 and Bug 689344 due to removing option for disabling account...
Good to know. Is there any possibility of this interaction being fixed in the 3.8 branch, or should I just close this WONTFIX? Have I picked a reasonable interpretation of the desired behaviour for downstream distributions that are stuck on 3.8?
I took a slightly simpler approach in bug 701373 by disallowing autologin in certain situations, which should prevent this bug from occurring. The code required to transition from states which shouldn't be reached in the first place adds quite a lot of complexity and I think it is probably not worth including.