Description of problem: passwd accepts Japanese letters as password. But this seems not well supported by other authenticators (apart from gnome-shell screensaver perhaps). I think it would be better for passwd to reject Japanese passwords completely. How reproducible: 100% Steps to Reproduce: 0. enable ibus to input Japanese (or Chinese) say 1. change password to Japanese word: eg: とうきょう 2. try to change password to something else Actual results: 1. changing password to とうきょう: : New password: とうきょう BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary work New password: とうきょう Retype new password: とうきょう passwd: all authentication tokens updated successfully. 2. $ passwd : (current) UNIX password: とうきょう passwd: Authentication token manipulation error $ Expected results: 1. passwd to reject とうきょう or 2. accept it Anyway at this time gdm, system-user-config etc do not allow ibus input so I think better to reject とうきょう completely. Additional info: I thought in the past passwd rejected non-Latin passwords, but testing on RHEL6 I see that it accepts Japanese for both 1 and 2 without warning. At least that allows changing the passwd to something else without needing root/sudo...
Thanks for your report. (Historically, non-ASCII, and even non-printable characters have been accepted in passwords, and using them is a very effective way to avoid brute-force attacks, so I'm not enthusiastic about prohibiting such passwords. I'd rather find and fix the cause of the "authentication token manipulation error".) I'm afraid I can't reproduce the problem. Testing * On F17 with gnome-terminal, copy&pasting the password above * On F17, when connected to F18 through ssh, copy&pasting the password above * On F18, enabling the Japanese (Kana) input source, and typing the "abcd" keys as a password (which is echoed as some CJK characters elsewhere in the terminal) In all of these cases, everything seems to work fine: I can set the password, (su myusername) accepts it, ssh connection accepts it, and I can also change it to something else. What am I missing? Is entering text through ibus somehow different from copy&pasting? Could you perhaps expand on the steps 0 and 1, please? I'm afraid I don't know enough about the input methods to even know whether I'm using ibus by enabling the "Japanese (Kana)" source.
(In reply to comment #1) > (Historically, non-ASCII, and even non-printable characters have been > accepted in passwords, and using them is a very effective way to avoid > brute-force attacks, so I'm not enthusiastic about prohibiting such > passwords. I'd rather find and fix the cause of the "authentication token > manipulation error".) (Right fair enough but to me this is a level 2 thing. There are characters which can't really be input on a kernel console for example basically/easily but only really in X or with an input method.) So probably European characters should be allowed but maybe not Asian characters - though arguably it is somewhat arbitrary... > I'm afraid I can't reproduce the problem. : > In all of these cases, everything seems to work fine: I can set the > password, (su myusername) accepts it, ssh connection accepts it, and I can > also change it to something else. > > What am I missing? Is entering text through ibus somehow different from > copy&pasting? Let me try again and see if I can reproduce it further. > Could you perhaps expand on the steps 0 and 1, please? I'm afraid I don't > know enough about the input methods to even know whether I'm using ibus by > enabling the "Japanese (Kana)" source. Actually "Japanese (Kana)" is a xkb layout (for ibus you want "Japanese (Anthy)") but it should be good enough for testing this I think.
I think this is a very sloppy slope on which you want to put the poor passwd command. :) It would have to grow probably pretty complicated table of allowed/disallowed characters which I am afraid we cannot fully maintain. And as you can see in comment#1 there are legitimate scenarios where such passwords are acceptable - what if the user accesses the system only remotely over ssh and never uses the console and gdm login with such password? I think this is at most a documentation issue.
(In reply to comment #3) > I think this is a very sloppy slope on which you want to put the poor passwd > command. :) It would have to grow probably pretty complicated table of > allowed/disallowed characters which I am afraid we cannot fully maintain. It would perhaps make sense for the GNOME password change dialog to prohibit characters that the GNOME login window can't accept (that dialog is also closer to the IM mechanism and can better judge which characters to refuse). > I think this is at most a documentation issue. The "Authentication token manipulation error" is very likely a real problem, not a documentation issue.
(In reply to comment #4) > > I think this is at most a documentation issue. > > The "Authentication token manipulation error" is very likely a real problem, > not a documentation issue. Sure, if that's a real reproducible problem.
I tried on the machine upgrade from F17 to F18 (RC1) and couldn't reproduce either. But I can reproduce easily on a fresh F18 install of RC2 with ibus input. Cut'n'paste seems ok.
Could it be, that some invisible character is inserted into the password entry when going through the ibus input? Note that the message "Authentication token manipulation error" is displayed in case that the original user's password is incorrect.
Created attachment 677208 [details] typescript (In reply to comment #6) > But I can reproduce easily on a fresh F18 install of RC2 with ibus input. > Cut'n'paste seems ok. Thanks. I have tried a F18 installation of RC2, system installation in en_US.UTF-8, and it still seems to work for me. Attached is a typescript; the original password was "foofoo", then I three times used the Anthy IM (Ctrl-J to switch to it, "toukyou Enter" to enter the Japanese characters for the password), and finally changed the password to something ASCII-only. I have also verified (by using a separate tab and (su - foo), and by ssh with the password copy&pasted from comment #0) that the password is accepted by other programs. Could you capture the password changes (both the one setting the Japanese password, and the one trying to use it) using strace, please? i.e. wait for the password prompt, then > strace -s 1024 -ff -o change1 -p $pid_of_the_passwd_process Note that the strace may include parts of your /etc/passwd and /etc/shadow, so please use a throwaway user account and edit the data related to your root and user account, if any.
(In reply to comment #8) > I have tried a F18 installation of RC2, system installation in en_US.UTF-8, Also tested a Japanese system installation, also seemed to be working. Not sure what I'm missing. - Default installation for the language, didn't touch keyboard or locale settings. GNOME used. - Created an user in firstboot. - Logged in with said user, started gnome-terminal. - Then switched to the Japanese (Anthy) input method - Tested it as described above.
Thank you for your detailed investigation and sorry for long delay to reply. I just tried with F19 Alpha and I don't see any error messages or warnings. Also tried latest F18 Live respin and works fine too. Closing - thanks