Bug 833253

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

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

(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.

(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.

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.

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.

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.

Ditto comment 6 for 13.1/KDE 4.11.2 host vizio.

Ditto comment 6 for 13.1/KDE 4.11.2 host gx62b.

Ditto comment 6 for 13.1/KDE 4.11.2 host gx270.

Still a problem in 13.1 final with all the latest updates applied (host vizio745).

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.

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.

Reassigning this to the default bugowner. This is NOT a KDE issue, but it seems more in the setup of PAM.

Created attachment 579637 [details]
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.

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.

(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.

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.

(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?

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

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

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?

on 13.1 the workaround is
pam-config --add --unix-nullok

In Fedora-20 the nullok option seems to be default
which is just a question of policy (permissive vs secure).

Debian uses nullok_secure

(In reply to Bernhard Wiedemann from comment #24)
> on 13.1 the workaround is
> pam-config --add --unix-nullok

This worked on a 13.1 and 13.2 host I just tried it on, including 'passwd -d' for the first times ever on any openSUSE installation.

A question that does remain is is there readily discoverable and simple enough documentation such that a user new to openSUSE or dependent on its previous behavior won't be stymied to the extent I was. I create users via script before ever starting X or YaST. Before this bug report I had no idea anything about how the passwd command is allowed to work was configurable. The string pam is absent from release notes for 12.3, 13.1 and 13.2.

That nullok is not set by default was a openSUSE decission, not the one of the package maintainer.
Else I'm not responsible for documentation and not the maintainer of the involved packages.

Hi Felix, it looks like a documentation issue. Would you like to open another documentation bug and close this one?

(In reply to Chenzi Cao from comment #27)
> Hi Felix, it looks like a documentation issue. Would you like to open
> another documentation bug and close this one?

It looks like more than a doc issue to me. On latest Linuxmint (17.2), latest Fedora (22), latest Ubuntu (15.04), latest Mageia (5), and latest Debian (Jessie), passwd -d <username> is sufficient to create a no password required user that works on the vttys. No doc lookups or non-default login system configuration is required on any of them to make it happen. Why does openSUSE need more security than its major competition?

Hi Karl, would you please help to have a look at here? Thank you!

Please provide a suitable release notes entry, if you think that that's needed.

coolo, do you think a release notes entry is required?

No, Felix should write a wiki page - or update an existant one. This has pretty much always been the case. It might be different to other distributions, but it's clearly not a case for release notes

Thanks for clarification.  Felix, you can consider this bug as a reminder or just close it, please.

(In reply to Stephan Kulow from comment #32)
> No, Felix should write a wiki page - or update an existant one. This has
> pretty much always been the case. It might be different to other
> distributions

Not might - is - compared to the other 5 of the top 6 distros on Distrowatch.

Someone who actually understands how security works and the reasoning for being different from other top distros will have to do any wiki writing that might occur. Insufficient understanding both specific to this bug and generally means I cannot fix it. Yet I remain of the opinion this is a bug that ought to be fixed.

I see. Now that means it won't be fixed then