[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
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c
FeiXiang Zhang
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c1
--- Comment #1 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c2
Hrvoje Senjan
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c3
Felix Miata
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
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
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c6
--- Comment #6 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c7
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c8
--- Comment #8 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c9
--- Comment #9 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c10
--- Comment #10 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c11
--- Comment #11 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c12
Raymond Wooninck
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c13
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c14
Raymond Wooninck
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c15
--- Comment #15 from Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c
zhang jiajun
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c16
--- Comment #16 from Raymond Wooninck
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c17
--- Comment #17 from Felix Miata
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
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c19
Felix Miata
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
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c21
Stephan Kulow
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c22
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c
Felix Miata
https://bugzilla.novell.com/show_bug.cgi?id=833253
https://bugzilla.novell.com/show_bug.cgi?id=833253#c
Stephan Kulow
participants (1)
-
bugzilla_noreply@novell.com