Arch Linux

Can you login to another user account that has a username that starts with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes?

OK, I will try it later when I get back.

OK, I added a new user john. john can log in. I added a new user 1user. 1user cannot log in, gets same errors as listed above. : (

I guess I am the only one going through this after all. I won't be back until Monday, but is there no way I can get around this??? I am completely locked out of both of my Arch Linux installations now, & totally without any warning. Systemd has caused me much suffering in the past, but never like this. This is a bit devastating to me, well kind of anyway, since I multi-boot different distros. In all the years I've been using different Linux distros, I've never been locked out like this.

What exactly did systemd suddenly change to do this??? All the programs like useradd can use a badname option, & even manually creating a username like mine is no problem with /etc/passwd & the rest of the system. Isn't there a way to tell systemd to use a badname option, or even just the UID number??? If anyone can hint me to whatever new setting systemd is using, it would be greatly appreciated.

I apologize for filing this bug report only to find out that I'm probably the only one hit by it. I know an issue like this is silly & unimportant to anyone, but I really disagree with enforcing such a thing so strongly. Actually, I just found the systemd bug reports. Maybe I can file the issue there next week & hope they don't get mad at me. I found someone else who seems to be having the same problem. Please see here: https://github.com/systemd/systemd/issues/15090

This is a guess, but I would not be surprised if the new userdb mechanism does not accept bad user names. If a comment I read on the systemd bug tracker [1] is accurate, systemd should fall back to the previous user management mechanisms in its absence. Those might still accept your user name. You could maybe try to stop systemd-userdbd.socket and systemd-userdbd.service before trying to log in? Not sure if that would be enough to test my theory.

[1] https://github.com/systemd/systemd/issues/15105#issuecomment-599084974

OK, I'm back again. Thanks for mentioning those things. I tried stopping both of them & restarting the display manager, & this completely failed. Nothing changed. I still could not log in with the display manager. I tried restarting the display manager & logging in multiple times after stopping the systemd-userdbd socket & service, & it failed the same way every time. I even tried disabling both of those things & rebooting, but after the reboot, they were both running again even though they were disabled.

I'm going to report this on the systemd github issue tracker. I expect it to get shot down immediately, but I'm going to try anyway. Since other people seem to be going through this problem as well, maybe some good will come from it.

For whatever good it may be worth, I'm also attaching my full boot logs here. I only edited out some UUIDs that I found in them.

Edit: Attached the files.

Although 15090 looks very similar it was for an account with the login name davis which does not have the same validity issue.

Oh, I see. I don't really know the details of how systemd works while a user is logging in, but to my untrained eyes, it seems like systemd is disagreeing with the rest of the system now. In looking through the logs, it seems that the login manager successfully authenticated the user to log in, but then systemd jumps in & disagrees. If a user already exists in the system, & is successfully authenticated to log in by the login manager, why would systemd jump in & say "Nope, I'm overriding your authorization"??? That is something that should not ever happen.

I think that if an already existing user is authenticated to log in by the login manager, then that should be it. Systemd should not jump in disagree. The different components must work in sync with each other. Does that mean that systemd is creating & using a different database than the rest of the system??? If that is the case, it will definitely lead to problems. There should only be 1 database that all login components can use & agree upon.

I also think that if there is a concern about a user with a bad name, then that concern should be made during the time of user creation, & not while logging in an already existing user. If a user already exists, they must be allowed to log in. Again, this goes with the idea of all components working in sync with each other. The programs that create user accounts, like useradd, allow a user to create an account with a "bad name". At that point, the user already knows the warnings that some programs may not work correctly. If the user creation programs allow such an option, than it should be expected that the user will always be able to log in to the system regardless of "bad name" or not.

If systemd is going to insist on refusing such logins, than all user creation programs must be changed to completely remove any type of "bad name" options so that all components are working in sync with each other. But changing multiple programs is not the sensible option to take. It makes more sense for systemd to allow an already existing user to log in as expected, especially since they were already authenticated to do so by the login manager.

Again, I don't know the details on how systemd works in this regard, but this is how my eyes see it. I'm not sure if this is actually the intention of the systemd developers or not, but if it is, I think the idea is a bit flawed. I certainly hope that any of the developers would rethink it, especially since falling back to the previous user management mechanism, as AK mentioned above, doesn't seem to be working.

BTW, sorry for such a long post. I tend to do that a lot & run out of spare time for the day.

https://github.com/systemd/systemd/issues/15141 thank you for opening the upstream bug report.

Fixed upstream via https://github.com/systemd/systemd/pull/15201