[Bug 833253] New: null passwords cannot be created (passwordless and null password account logins rejected KDE and vttys; )
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c0 Summary: null passwords cannot be created (passwordless and null password account logins rejected KDE and vttys; ) Classification: openSUSE Product: openSUSE Factory Version: 13.1 Milestone 3 Platform: All OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: mrmazda@earthlink.net QAContact: qa-bugs@suse.de Found By: --- Blocker: --- Created an attachment (id=551106) --> (http://bugzilla.novell.com/attachment.cgi?id=551106) 13.1m3 y2logs from host big41 To reproduce: 1-install minimal X normally but without creating any regular user(s) 2-set grub cmdline(s) to include 3 parameter 3-set solver.onlyRequires=true in /etc/zypp.conf 4-install minimalist via zypper and set default KDM/KDE (3 and/or 4) 5-create group account (e.g. # groupadd -g 1999 mygroup) 6-create user account (e.g. # useradd -g 1999 -u 1999 myaccount) 7a-delete password (e.g. # passwd -d myaccount), or 7b-set password null (e.g. #passwd myaccount, <ENTER>, <ENTER>) 8-attempt to login with new user account (hostname login: myaccount)(in KDM or vtty) 9-passwd -S myaccount Actual results: 1a-(KDE) {1}-Login failed (normal user) {2}-Login succeeds (root without entering any password) 1b-(vtty) Login incorrect 2-(vtty) login prompt refreshes 3-(passwd -S) myaccount NP 01/01/1970 99999 7 -1 4-attempt to set passwd null (7b above) fails as follows: New: password: BAD PASSWORD: it is WAY too short BAD PASSWORD: is a palindrome Retype new password: No password supplied passwd: Authentication token manipulation error passwd: password unchanged Expected results: 1-(vtty) Last login XXX XXX ## ##:"##:## on ttyX 2-(vtty) Have a lot of fun... 3-(all KDE) login succeeds 4-(passwd -S) myaccount PS <create?/change? date> 0 99999 7 -1 5-attempt to set null password succeeds Comments: 1-applies also to 12.3 (local hosts gx150 & big41) 2-In pre-12.3 openSUSE versions, deleting password failed too, but setting password null worked. In Fedora 19 (as in previous versions) and Mageia 3 (as in previous versions, and Mandriva, and Mandrake), setting password null fails, but deleting password works. 3-IIRC (I need to verify if I can figure out which systems this applies to), 12.2 systems (at least those with sysvinit-init installed) for which users and null password(s) was/were set and which were upgraded to 12.3 via zypper continue to accept logins. 4-On 2 of the 4 installations, once KDM had been started after the users and passwords had been set and at least one reboot, this bug permanently disappeared, remaining only on hosts gx150 running 13.1 and KDE3, and host big41 running 12.3 and KDE4. 5-As I needed 12.3 to work on big41, I copied relevant lines from /etc/shadow on big41's 12.2, which solved the problem at least so far as allowing logins from null password accounts. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c FeiXiang Zhang <fxzhang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |kde-maintainers@suse.de |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c1 --- Comment #1 from Felix Miata <mrmazda@earthlink.net> 2013-10-14 20:02:56 UTC --- In 13.1RC1/KDE4 installation I selected DES, but still failed tty logins happen on host hs80e, while succeeding via KDM. Apparently the difference is I have set NoPassUsers=* in kdmrc, which works around the failure of the underlying authorization system to permit logins without requiring any password be typed. Ditto for host hs80e with 12.3. Again I was able to login as normal user passwordless in both 12.3 and 13.1 after copying from 12.2's /etc/passwd and /etc/shadow. y2logs from hs80e: http://bugzilla.novell.com/attachment.cgi?id=563225 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c2 Hrvoje Senjan <hrvoje.senjan@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO CC| |hrvoje.senjan@gmail.com InfoProvider| |mrmazda@earthlink.net --- Comment #2 from Hrvoje Senjan <hrvoje.senjan@gmail.com> 2013-10-15 19:24:14 UTC --- Felix, can you try with latest upadates in 13.1? Make sure you have: Fri Oct 11 20:46:02 UTC 2013 - hrvoje.senjan@gmail.com - Adjust kdm-sysconfig-values.diff so it doesn't dictates AllowNullPasswd option (bnc#833634) - Make main package Recommends kde-gtk-config (bnc#845592) in rpm -q --changelog kdm | head. I am not sure is that already published for 13.1 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c3 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|mrmazda@earthlink.net |hrvoje.senjan@gmail.com --- Comment #3 from Felix Miata <mrmazda@earthlink.net> 2013-10-15 19:59:16 UTC --- (In reply to comment #2)
Felix, can you try with latest upadates in 13.1?
I don't see how that can help on systems on which I've already implemented the copy from workaround. That will have to happen on others that are in queue for update from beta1 to RC1 that haven't had the workaround applied, which I don't have inventory on. That said, I don't see how anything to do with KDE will solve the underlying problem, since kdmrc seems to provide the higher level workaround/solution. The more fundamental problem is this from comment 0: 4-attempt to set passwd null (7b above) fails as follows: New: password: BAD PASSWORD: it is WAY too short BAD PASSWORD: is a palindrome Retype new password: No password supplied passwd: Authentication token manipulation error passwd: password unchanged .. In Fedora 19 (as in previous versions) and Mageia 3 (as in previous versions, and Mandriva, and Mandrake), setting password null fails, but deleting password works. IOW, only root can login on a vtty, and that only because root (and only root) has a password. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c4 --- Comment #4 from Felix Miata <mrmazda@earthlink.net> 2013-10-16 04:48:03 UTC --- (In reply to comment #2)
Make sure you have: Fri Oct 11 20:46:02 UTC 2013 - hrvoje.senjan@gmail.com
- Adjust kdm-sysconfig-values.diff so it doesn't dictates AllowNullPasswd option (bnc#833634) - Make main package Recommends kde-gtk-config (bnc#845592)
in rpm -q --changelog kdm | head. I am not sure is that already published for 13.1
Apparently not. On a just dup'd system latest entry is 07 Oct. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c5 --- Comment #5 from Felix Miata <mrmazda@earthlink.net> 2013-10-24 20:00:13 UTC --- During installation of 13.1RC1 just now via HTTP I attempted to create one ordinary user with blank password fields, but YaST refused to let me, unlike the YaST of versions past. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c6 --- Comment #6 from Felix Miata <mrmazda@earthlink.net> 2013-11-10 08:16:35 UTC --- Having zypper -v dup'd hosts gx110 & gx27b from RC2 with kdebase3-kdm, and host t2240 with kdm-4.11.2-4.1, to whatever is in the 13.1 oss, non-oss & update repos now, still what happens attempting to set null password is: # passwd <loginname> New: password: BAD PASSWORD: it is WAY too short BAD PASSWORD: is a palindrome Retype new password: No password supplied passwd: Authentication token manipulation error passwd: password unchanged YaST2 still refuses to accept blank passwords: "No password entered. Try again." kdmrc contains uncommented: AllowNullPasswd=true NoPassEnable=true NoPassAllUsers=true NoPassUsers=* In spite of inability to login on a vtty, both KDMs do accept login without passwd entry, confirming this is not a KDE3 or KDE4 issue. kdebase3-kdm changelog head has entries by anixx@ 09 Aug, 10 Sep, 07 Nov, none of which mention anything in comment 2. kdm4's changelog includes the comment 2 reference re AllowNullPasswd. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c7 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|null passwords cannot be |null passwords cannot be |created (passwordless and |created (passwordless and |null password account |null password account |logins rejected KDE and |logins rejected on vttys; ) |vttys; ) | --- Comment #7 from Felix Miata <mrmazda@earthlink.net> 2013-11-10 08:25:59 UTC --- Conforming summary to comment 6: not an issue with either KDM; only bash/vttys cannot be logged into due to accounts not able to be updated to passwordless or null passwd. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c8 --- Comment #8 from Felix Miata <mrmazda@earthlink.net> 2013-11-10 17:38:36 UTC --- Ditto comment 6 for 13.1/KDE 4.11.2 host vizio. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c9 --- Comment #9 from Felix Miata <mrmazda@earthlink.net> 2013-11-13 04:23:12 UTC --- Ditto comment 6 for 13.1/KDE 4.11.2 host gx62b. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c10 --- Comment #10 from Felix Miata <mrmazda@earthlink.net> 2013-11-13 18:21:25 UTC --- Ditto comment 6 for 13.1/KDE 4.11.2 host gx270. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c11 --- Comment #11 from Felix Miata <mrmazda@earthlink.net> 2014-02-21 08:21:58 UTC --- Still a problem in 13.1 final with all the latest updates applied (host vizio745). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c12 Raymond Wooninck <tittiatcoke@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tittiatcoke@gmail.com InfoProvider|hrvoje.senjan@gmail.com |mrmazda@earthlink.net --- Comment #12 from Raymond Wooninck <tittiatcoke@gmail.com> 2014-02-21 09:45:57 UTC --- I don't know why this bug was ever assigned to the KDE maintainers, as that it is clear that it was indicated that the issue also occurs when logging in on a vtty. Felix, did you check if pam has been setup correctly to allow this ? I can imagine that the default setup would be to prevent passwordless logins. Accounts without password (i.e. where the password has been cleared with "passwd -d") may authenticate without being asked for a password if the nullok option is present in /etc/pam.d/common-auth. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c13 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|mrmazda@earthlink.net | --- Comment #13 from Felix Miata <mrmazda@earthlink.net> 2014-02-21 10:44:21 UTC --- Prior to the weeks immediately preceding filing this bug 6 months ago I'd never that I can recall in any distro in over a decade of Linux use encountered an inability to set one or the other of either null password or no password for a regular user account. After running passwd -d username, username trying to login gets "Login incorrect" by pressing only <return> when "Password:" prompt is presented. I don't know anything about pam. AFAICT, /etc/pam.d/common-auth remains as it was as provided by whatever rpm it came from. Whatever accounts for the presence of .rpmnew files in /etc/pam.d/ I have no idea. The string "nullok" is present on uncommented lines in common-password.rpmnew, common-password, common-password-pc and common-password.pam-config-backup. As indicated in http://lists.opensuse.org/opensuse-kde/2014-02/msg00029.html the (2013-06-04; milestone3?) host vizio745 13.1 installation clearly has some kind of auth problem, as only root can get YaST to run. pam-1.1.8-3.1 is currently installed version. Apparmor and SuSEfirewall are not installed. I don't know how to tell which of the four auth methods offered during installation was selected or is in use. I've not used the default selection for several installations, in part because of this bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c14 Raymond Wooninck <tittiatcoke@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kde-maintainers@suse.de |bnc-team-screening@forge.pr | |ovo.novell.com --- Comment #14 from Raymond Wooninck <tittiatcoke@gmail.com> 2014-02-21 11:02:11 UTC --- Reassigning this to the default bugowner. This is NOT a KDE issue, but it seems more in the setup of PAM. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c15 --- Comment #15 from Felix Miata <mrmazda@earthlink.net> 2014-02-22 03:32:04 UTC --- Created an attachment (id=579637) --> (http://bugzilla.novell.com/attachment.cgi?id=579637) y2logs from 64 bit host vizio Confirming problem exists in 13.1 final via fresh minimal X DVD installation. Procedure: 1-groupadd -g <newgroupnumber> 2-useradd -g newgroupnumber -u <newusernumber> <newusername> 3a-passwd -d newusername, or 3b-passwd newusername <enter> <enter> 4-attempt to login at vtty3 shell prompt by newusername fails I added skeletal kdm/kde with zypper, then: In kdmrc: AllowNullPasswd=true NoPassEnable=true NoPassUsers=* NoPassAllUsers=true Newusername is able to login successfully via theme-free KDM without typing anything, just clicking his icon, then the login button. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c zhang jiajun <jzhang@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jzhang@suse.com AssignedTo|bnc-team-screening@forge.pr |coolo@suse.com |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c16 --- Comment #16 from Raymond Wooninck <tittiatcoke@gmail.com> 2014-02-27 09:22:11 UTC --- Felix, So the bug remains on the level of PAM as that the login at the vtt3 shell fails. However if you add some additional configuration options to kdmrc, then it seems that KDM is willing to accept the passwordless user. So as indicated this is not a KDM OR KDE issue, but seems more PAM related. Therefore I reassigned this already. As that these are quite unique situations, I hope you can understand that we are not going to add these settings to the standard/default kdmrc. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c17 --- Comment #17 from Felix Miata <mrmazda@earthlink.net> 2014-02-27 09:55:56 UTC --- (In reply to comment #16)
I hope you can understand that we are not going to add these settings to the standard/default kdmrc.
I don't know why anyone would think I expect changes to default kdmrc settings on account of this bug. Neither do I expect users to be able to login when the passwd command rejects null passwords, and passwd -d fails to dispense with need for any password. What I do expect is to be able to have ordinary users able to login in "runlevel 3" without need to type any password, like I could in 12.3, when the current SuSE Linux kernel was 2.4.18, when the current Corel Linux kernel was 2.2.14, and when the current RedHat kernel was 2.0.32, without need to graft content from an earlier or alien installation into 13.1's or Factory's /etc/passwd and /etc/shadow. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c18 Raymond Wooninck <tittiatcoke@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #18 from Raymond Wooninck <tittiatcoke@gmail.com> 2014-02-27 10:17:38 UTC --- There is a very fast solution to your issue. You edit the file /etc/pam.d/common-auth and there should be two lines in there: auth required pam_env.so auth required pam_unix2.so Behind each of the above lines you put the word nullok, so that it looks like this: auth required pam_env.so nullok auth required pam_unix2.so nullok Save the file and your issue is resolved. Users no longer require a password if there is no password defined and the behavior is now as you want it. If you had read my comment (comment#12) and had looked at the pam settings and manuals instead of bringing up all kind of historical information about how older versions were able to do this, etc, then you could have easily resolved the issue yourself !! But with the information provided in this comment, I am closing this bug report as resolved as that it is possible to have the required behavior if you set up the system in that way. That it is not the default setup as that it was in the past is a different story, but I guess editing two files as a system administrator should be easy enough. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c19 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | Status Whiteboard| |regression --- Comment #19 from Felix Miata <mrmazda@earthlink.net> 2014-02-27 12:08:28 UTC --- (In reply to comment #18)
There is a very fast solution to your issue.
You edit the file /etc/pam.d/common-auth
I think not. That is a symlink to common-auth-pc, which contains the following (in 13.2) first lines: #%PAM-1.0 # # This file is autogenerated by pam-config. All changes # will be overwritten. That file exists in neither Mageia 4 nor Fedora 20 nor Rawhide. F20 does have something similar, though larger in uncommented line count, passwd-auth-ac: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account required pam_permit.so password requisite pam_pwquality.so try_first_pass retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
and there should be two lines in there:
auth required pam_env.so auth required pam_unix2.so
Behind each of the above lines you put the word nullok, so that it looks like this:
auth required pam_env.so nullok auth required pam_unix2.so nullok
Save the file and your issue is resolved. Users no longer require a password if there is no password defined and the behavior is now as you want it.
If you had read my comment (comment#12) and had looked at the pam settings and manuals instead of bringing up all kind of historical information about how older versions were able to do this, etc, then you could have easily resolved the issue yourself !!
You assume too much. I get little out of man pages due to their extreme dearth of examples. You referred to pam, but I know nothing about pam, as I never needed to know until now. And I still don't really. man pam is barely a screenful, with no reference to common-auth or common-auth-pc. I don't expect your suggested edits to help anything given the warning comment in that config file.
But with the information provided in this comment, I am closing this bug report as resolved as that it is possible to have the required behavior if you set up the system in that way. That it is not the default setup as that it was in the past is a different story, but I guess editing two files as a system administrator should be easy enough.
Easy enough maybe only with readily discoverable and understandible docs, and certainly not as easy as in previous releases and competing distros. This particular added complication makes dispensing with normal users and doing all as root look inviting too. This impediment was not part of previous openSUSEes, and remains not in Fedora 20, Fedora 21, and Mageia 4, to edit any config files in order to enable a user to require no password to login. Now as before in both Fedora and Mageia, passwd -d username is all that's required to enable passwordless vtty login. The passwd -d method never worked in openSUSE (why?), but passwd would accept null passwords for non-root users (unlike all other distros I can recall ATM). So, I'm reopening, on account of no indication how to cause the desired result without suggested edits being overwritten at autogeneration time, whenever that is. Where does one put nullok that automagic will put it in instead of stripping it out? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c20 Stefan Brüns <stefan.bruens@rwth-aachen.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan.bruens@rwth-aachen.d | |e --- Comment #20 from Stefan Brüns <stefan.bruens@rwth-aachen.de> 2014-08-14 13:44:13 UTC --- man pam-config: --unix2-nullok Add nullok option to all pam_unix2.so invocations. man pam_unix2: nullok Normally the account is disabled if no password is set or if the length of the password is zero. With this option the user is allowed to change the password for such accounts. This option does not overwrite a hard- coded default by the calling process. So "pam-config --add --unix2-nullok" should solve your problem. regarding kdm, AllowNullPasswd=true bypasses pam-auth -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c21 Stephan Kulow <coolo@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |WONTFIX --- Comment #21 from Stephan Kulow <coolo@suse.com> 2014-09-17 16:11:52 CEST --- I don't see a bug - pam just works the way it works - awefully. If you think more documentation might help, feel free to provide it: openSUSE documentation is in activedoc.opensuse.org -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c22 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | --- Comment #22 from Felix Miata <mrmazda@earthlink.net> 2014-09-17 12:55:46 EDT --- As if the subject wasn't clear enough, the bug is that if one chooses Mageia or Fedora to install and use instead of openSUSE, all that's required for a normal user to need to type no password to login is for root to passwd -d his account. But if one chooses openSUSE, where passwd -d never worked in the first place, one must either: 1-dive into documentation first and discover how to make changes to files that upgrading will overwrite, necessitating repeating the process if a new user needs to be added after the upgrading, or 2-manually edit /etc/shadow Why should openSUSE be different in this basic functionality from other major distros? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |coolo@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=833253 https://bugzilla.novell.com/show_bug.cgi?id=833253#c Stephan Kulow <coolo@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED CC| |coolo@suse.com InfoProvider|coolo@suse.com | AssignedTo|coolo@suse.com |ckornacker@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com