Fedora Account System
Red Hat Associate
Red Hat Customer
In openQA, we have a test which runs a Turkish install. Usually, the user password used is 'weakpassword', but for unimportant reasons, the test recently ran with the user password as '[redacted]'. When typed on a Turkish keyboard layout, this becomes 'ğredactedü'. When we try to use that as the user password in gnome-initial-setup, g-i-s accepts it fine, but chpasswd fails to set it. This results in an unusable system - handoff from gnome-initial-setup to a logged-in session does not work, and on reboot you cannot log in either. In the journal, we see these messages indicating chpasswd barfed: Eki 09 19:30:06 fedora accounts-daemon[1001]: request by system-bus-name::1.73 [/usr/libexec/gnome-initial-setup pid:2173 uid:60579]: create admin user 'test' Eki 09 19:30:06 fedora useradd[2607]: new group: name=test, GID=1000 Eki 09 19:30:06 fedora useradd[2607]: new user: name=test, UID=1000, GID=1000, home=/home/test, shell=/bin/bash, from=none Eki 09 19:30:06 fedora useradd[2607]: add 'test' to group 'wheel' Eki 09 19:30:06 fedora useradd[2607]: add 'test' to shadow group 'wheel' Eki 09 19:30:06 fedora accounts-daemon[1001]: request by system-bus-name::1.73 [/usr/libexec/gnome-initial-setup pid:2173 uid:60579]: set password and hint of user 'test' (1000) Eki 09 19:30:06 fedora accounts-daemon[2626]: chpasswd: (line 1, user test) invalid password hash Eki 09 19:30:06 fedora accounts-daemon[2626]: chpasswd: hata algılandı, değişiklikler görmezden gelindi Eki 09 19:30:06 fedora gnome-initial-setup[2173]: SetPassword call failed: GDBus.Error:org.freedesktop.Accounts.Error.Failed: running '/usr/sbin/chpasswd' failed: Alt işlem 1 kodu ile sonlandı Eki 09 19:30:06 fedora accounts-daemon[1001]: Unable to open /etc/tcb: Böyle bir dosya ya da dizin yok Eki 09 19:30:07 fedora unix_chkpwd[2634]: password check failed for user (test) Eki 09 19:30:07 fedora gdm-password][2628]: pam_unix(gdm-password:auth): authentication failure; logname= uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=test Eki 09 19:30:07 fedora audit[2628]: USER_AUTH pid=2628 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="test" exe="/usr/libexec/gdm-session-worker" hostname=fedora addr=? terminal=/dev/tty1 res=failed' Eki 09 19:30:07 fedora gdm-password][2628]: PAM authentication for user: test Eki 09 19:30:07 fedora gdm-password][2628]: Captured PAM_AUTHTOK of length 12 bytes Eki 09 19:30:07 fedora gdm-password][2628]: Captured authentication token of length 12 bytes, stashing for session Eki 09 19:30:07 fedora gdm-password][2628]: Stashed password to try later in open session Eki 09 19:30:08 fedora audit[2628]: USER_LOGIN pid=2628 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000 exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=failed' Eki 09 19:30:08 fedora gnome-initial-setup[2173]: PAM module error: Üzgünüm, parola kimlik doğrulaması işe yaramadı. Lütfen yeniden deneyin.
Huh. It actually seems worse than I thought, it even seems to be failing when we use 'weakpassword' as the password - see https://openqa.stg.fedoraproject.org/tests/7146020 . Will look into this more tomorrow/Monday. I think this is only affecting Rawhide for some reason, but I'll double check.
OK, so I can consistently reproduce this now. Steps: 1. Get a current F45 or Rawhide Workstation live image (e.g. https://kojipkgs.fedoraproject.org/compose/branched/Fedora-45-20261013.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-45-20261013.n.0.x86_64.iso ) 2. Boot, launch the installer. Change the language to Turkish 3. Click the blue link to the right of "Klavye". This will launch the GNOME keyboard layout panel 4. Add the plain Turkish keyboard layout, remove the US keyboard layout 5. Close the keyboard layout panel, return to the installer. Wait for the keyboard layout shown next to "Klavye" to change from "us" to "tr" 6. Proceed through the installer (click "Sonraki", then "Tum diski kullan" and "Sonraki" again, then "Sonraki" again, then check the checkbox and click "Verileri sil ve kur"). When install completes, boot to the installed system 7. Proceed through g-i-s (click "Ileri") to the user screen, set user name to "test" 8. Proceed to the password screen, set password to "weakpassword" 9. Click "Ileri" What ought to happen is you get to a desktop as test, but instead the system just gets stuck. If you reboot it you'll be at a GDM login prompt with no user account available. The journal shows the errors I pasted above. I hacked shadow to log the password hash it doesn't like, and ran an install with the hacked shadow. Here's what it says: Oct 13 13:03:09 fedora accounts-daemon[2337]: chpasswd: (line 1, user test) invalid password hash $y$j9T$lChB5KbMj.6n51V3DjPfn0$6WyruF4YWm9GDgKx2mik5QEHE6J4m2RVXXegiqrfjI8
Proposing as a Final blocker as it does seem pretty bad, it kinda seems like normal Turkish Workstation installs may be affected. Not sure if there's anything special about 'weakpassword' or it would happen with *any* password. I'll try a few others.
Poked at this some more but can't quite pin it down. That string *should* pass the regex check and when I isolate the regex check and run it locally, it does, even with LC_ALL=tr_TR.UTF-8 . I *suspect* what's going on is something subtle with the Turkish locale and the definition of `[a-z]` so far as regex parsing goes (Turkish is a bit unusual about letters).
Looks like this bug already existed in F44 too, we just didn't spot it at the time.
Adam, (In reply to Adam Williamson (Fedora) from comment #4) > That string *should* > pass the regex check and when I isolate the regex check and run it locally, > it does, even with LC_ALL=tr_TR.UTF-8 . For me it doesn't. With: ''' static bool match_regex(const char *pattern, const char *string) { regex_t regex; int result; if (regcomp(®ex, pattern, REG_EXTENDED) != 0) return false; result = regexec(®ex, string, 0, NULL, 0); regfree(®ex); return result == 0; } int main(void) { const char *loc = setlocale(LC_ALL, ""); printf("locale in effect : %s\n", loc ? loc : "(setlocale failed!)"); printf("[a-z] matches i : %d\n", match_regex("^[a-z]$", "i")); printf("[A-Za-z] match i : %d\n", match_regex("^[A-Za-z]$", "i")); printf("[A-Za-z] match I : %d\n", match_regex("^[A-Za-z]$", "I")); return 0; } ''' where `match_regex()` is a copy of https://github.com/shadow-maint/shadow/blob/e9bc595fd20558cf51aef096db262232090e8fb8/lib/chkhash.c#L18 ``` $ LC_ALL=C ./check locale in effect : C [a-z] matches i : 1 [A-Za-z] match i : 1 [A-Za-z] match I : 1 $ LC_ALL=tr_TR.UTF-8 ./check locale in effect : tr_TR.UTF-8 [a-z] matches i : 0 [A-Za-z] match i : 0 [A-Za-z] match I : 0 ``` -- in `tr_TR.UTF-8` locale regular letters 'i'/'I' do *not* fall into '[a-z]'/'[A-Z]' ranges. That's because of 'ı'/'İ'. I bet a lot of sw was bitten by this many times..
Adam, is there a way to try https://github.com/alexey-tikhonov/shadow/commit/0bc412257a05ac773586091bb8b595911a7b3348 ?
> -- in `tr_TR.UTF-8` locale regular letters 'i'/'I' do *not* fall into '[a-z]'/'[A-Z]' ranges. > That's because of 'ı'/'İ'. Aha! Yes, that's more or less exactly what I was expecting, but I was confused that I couldn't reproduce it, but - not being a C coder - I did not realize I needed an explicit `setlocale` call in my test script. If I add one, it also reproduces for me: [adamw@toolbx fedora-toolbox-44 ~]$ ./crypttest locale in effect : en_CA.UTF-8 Generated Salt Configuration: $y$j9T$n1FCuiytsO72//12.wem6/ Final Secure Hash (Store this in DB): $y$j9T$n1FCuiytsO72//12.wem6/$V0/t/jfXZVSfMyZBLbGphuenXNdNzhdktjkOxpfUgD4 Hash OK! Known Hash OK! [adamw@toolbx fedora-toolbox-44 ~]$ LC_ALL=tr_TR.UTF-8 ./crypttest locale in effect : tr_TR.UTF-8 Generated Salt Configuration: $y$j9T$dyL/n0Rlnjj1BaXYnWzGN. Final Secure Hash (Store this in DB): $y$j9T$dyL/n0Rlnjj1BaXYnWzGN.$aFSIFFmmXjTbY0Khh2HHfwHMnIl4If3WxPuKvBl9Q/4 Hash not OK! Known Hash not OK! > I bet a lot of sw was bitten by this many times.. Yeah, it's a fairly well-known issue *if* you do localization testing :D > Adam, is there a way to try https://github.com/alexey-tikhonov/shadow/commit/0bc412257a05ac773586091bb8b595911a7b3348 ? Yes, I can do that. Thanks for the quick fix. Will report back soon.
Fix looks good, after a few rounds of testing. Thanks! It would be great if we could get it in official Rawhide and F45 builds/updates ASAP.
Also proposing as an FE, as that's an easier vote.
Upstream PR: https://github.com/shadow-maint/shadow/pull/1772
+3 FE in https://forge.fedoraproject.org/quality/blocker-review/issues/2226 , marking accepted. I want to get an RC built soon and it'd be good to include this fix, so I will backport the fix shortly.
FEDORA-2026-78aa6059e7 (shadow-utils-4.20.0-2.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-78aa6059e7
FEDORA-2026-78aa6059e7 has been pushed to the Fedora 45 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-78aa6059e7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-78aa6059e7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2517109 has been marked as a duplicate of this bug. ***
+4 for blocker in https://forge.fedoraproject.org/quality/blocker-review/issues/2226 now, upgrading to accepted blocker.
Fix looks good here. I ran a Turkish install of RC1 and it worked fine; I checked the password hash and it has an 'i' in it. So I think we're good.
(In reply to Alexey Tikhonov from comment #11) > Upstream PR: https://github.com/shadow-maint/shadow/pull/1772 Fixed upstream as of https://github.com/shadow-maint/shadow/commit/76b02d12ee3a42afb82c200b2da98623a06061e2
FEDORA-2026-78aa6059e7 (shadow-utils-4.20.0-2.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.