Hi everyone. LightDM 1.33.1 has been released with a bug fix that broke user switching and restoring to locked sessions.
This should have been spotted, so here is all the information, retold as best as I can. I am not naming any names, nor am I placing blame on anybody but myself. I somehow spent an hour typing this post, so I hope I got all the information correct and as accurate as possible.
What Happened
logind had a property called CanMultiSession, introduced ~2014. However, there was an issue with this that caused the property to be set to “false” incorrectly. This was fixed in 2020 in systemd 246. Shortly afterwards, the CanMultiSession property was removed. [ML discussion]
To complicate things more, once CanMultiSession was fixed, since LightDM 1.33.0 included a patch to disable user switching when logind says it should be disabled. For versions of systemd before 246, this is not a problem. But for versions later, since the CanMultiSession property no longer existed, it would return “false” all the time. This was even acknowledged in the commit message:
Note: systemd-logind v245 and older erroneously report CanMultiSession=no on non-seat0 seats even when it is supported. This change will break those users. See <systemd/systemd#15337>.
The intent, of course, was not to break it for users. As far as LightDM (and I) was concerned, it was a proper bug fix. And I released it with 1.33.0 without knowing the property was removed. This lead to the breakage.
Why it took me so long to realize what happened
Even when I was going through the changes for the LightDM 1.33.0 NEWS file and changelog, I did see the commit, but I did not read the extended description.
I also should have caught this in testing. Yes, I was new, and eager to get the release out there, but I did not really play around with different config options. I only have one user on my system, so I didn’t even consider user switching and I didn’t test it. As long as the automatic tests passed and everything worked for me, (login, logout, switching desktop environments), I wasn’t concerned.
And even if I didn’t see it in testing, I should have paid attention when going through the backlog of GitHub Issues. There was an issue opened about the bug. There is no excuse for me missing this. The bug was opened in 2025 and it said it was on the latest commit. I think this was one of the (many) issues that I did not quite yet decide how I wanted to categorize it, so I skipped over it.
Now, I knew that CanMultiSession would eventually have to be set to true by default, as another PR for responding to SecureAttentionKey requests, actually required this. While looking to make sure that everything in terms of CanMultiSession logic checking was removed, I stumbled upon that prior issue and thought that the PR that would do this would help (see this comment).
Then, two days ago, an issue about not being able to unlock sessions was opened. The reporter, and another person found that applying the PR would fix the issue.
Hesitancy
Given everything that has been happening recently (LLM/bot-ran accounts, the XZ Utils backdoor situation, and a report from LWN about how LLMs would make multiple accounts to pressure maintainers into accepting patches), I have been very weary of social engineering. Especially for a codebase that was:
- Not actively maintained
- Had a huge backlog of issues and pull requests, many of them lacking information, or bug reproduction instructions
- Was gaining new maintainers who were totally unfamiliar with the codebase (like myself)
I have been taking all issues, new contributions and comments from others with a grain of salt, unless I could verify the user as a “trustworthy” person.
For this reason, I did not see any urgency to the bug. I actually opened a poll in Matrix of whether to release a 1.33.1 tag, and thought I would do so around tomorrow. I did this to try to get a general view of what people wanted, instead of just having one person influence my choices.
Finally realizing the urgency
When I was pinged about testing the SecureAttentionKey PR to see if it worked, now that the required patch about setting CanMultiSession to true by default was merged, I tested it myself, and out of curiosity, took the time to see if it also fixed that bug about not being able to switch user. Indeed, it did. The patch had solved the problems. Now I realized how urgent the bug was.
I was checking on Repology to ensure packagers were moving 1.33.0 into their repos, but I also noticed that Fedora Rawhide had already had this patch applied a few days ago, and overnight, the patch was applied in NixOS.
After I had figured this all out, I closely read the issues (because seeing all the different definitions: “login”, “user”, “switch”, “seat”, “unlock”, “session” can be confusing when considering them all at once), and was finally able to truly understand the bug report, and then realize that this critical bug was under my nose the entire time.
So I released 1.33.1 just now to prevent further breakage for users (and other packagers who were about to ship a regression), and wrote this post to explain what happened.
Apologies
I am sorry for not having paid attention to details, and missing the bug. I am also sorry for not knowing the technological lingo as I continue learning more about the codebase and the components around it. This is my first time working with logind and learning about the concepts of sessions, seats, etc. and putting it into practice in the context of LightDM and basic ideas of “user login” or “user switch screen”. It’s like learning a new language, but not knowing the different ways the idea of “I want to eat” can be conveyed.
I also would like to apologize if I have came off as “ignorant” towards anyone (the “hesitation” of social engineering). Moving forward, I’ll try to be a bit more open minded.
Thanks
Names listed are GitHub usernames.
- fulalas for the reporting the bug about not being able to switch user
- laniakea64 for reporting the bug about not being able to unlock session
- iczelia for reproducing, triaging the problem
- n3rdopolis for being on top of everything: sending the patch to fix this, attempting to keep LightDM up to date with the
SecureAttentionKeyPR which required the patch in the first place, and for explaining everything that happened (part 1) (part 2)
