Bug 19318

Setting as release blockers for now as having empty passwords should be supported.

Priority: Normal => release_blocker
Blocks: (none) => 17523

It might also be worth reporting upstream (bugs.kde.org) in parallel to this issue.

no, we will test and ask for a report if this is an upstream issue.

CC: (none) => mageia

I'm going to guess this is also not an upstream bug and is a problem with our PAM.  Perhaps related to Bug 19103.

As I did there, you can use kcheckpass to check directly its ability to accept your password.

I just tested on a fresh cauldron and i can't reproduce.

May this be an upgrade issue ?

Status: NEW => UNCONFIRMED
Ever confirmed: 1 => 0

is this bug still valid for you with plasma 5.8 Beta ?

Still valid on this system upgraded from mga5 before summer, with plasma 5.7.95, also with fresh created user.  Iĺl try again when 5.8 comes down...

Oh... I am using lxdm to log in... if that patters

Created attachment 8427 [details]
journalctl -ab from first login of fresh passwordless user test2

Output of journalctl -ab from first login of fresh passwordless user test2.
I loged in, locked screen tried unlock: fail.
Then logged in as root and grabbed this.

@#7: s/patters/matters

.xsession-errors in that user home is zero bytes !

i will do a mga 5 to 6 update to test then.

i still dont reproduce. 
Can someone else reproduce the issue ?

Aha! try this!

( Performed on fresh system: Fresh network install of cauldron plasma 64 bit four days ago, updates today. )

During install i created a user with all default settings (just filled in full name "test" login name "test", no password).  For this user plasma locker works.

Now use MCC to create another user with no password.  For *this* user plasma locker fail unlocking!

In case it have some effect in the issue: 

1) the system also have task-cinnamon, -enlightenment, -lxde, -mate.

2) DM=lxdm, because it is the most child friendly DM
2b) Bug 19536 - GDM refuse to login users with no password

ok i reproduce now. 
Seems a pam issue as it works with user created on mga5 but not on users created on mga6.

Status: UNCONFIRMED => NEW
Ever confirmed: 0 => 1

(In reply to Nicolas Lécureuil from comment #14)
> ok i reproduce now. 
> Seems a pam issue as it works with user created on mga5 but not on users
> created on mga6.

CC'ing a bunch of pam committers

CC: (none) => anssi.hannula, cjw, fundawang, luigiwalser, mageia, mageia, marja11, olav, pterjan, thierry.vignaud, tmb
Source RPM: plasma-workspace-5.7.4-2.mga6.src.rpm => plasma-workspace-5.7.4-2.mga6.src.rpm, pam?

I doubt that's a pam issue if it works for some users and not for others...
You should compare their entries in /etc/{passwd,shadow}

(In reply to Nicolas Lécureuil from comment #14)
> ok i reproduce now. 
> Seems a pam issue as it works with user created on mga5 but not on users
> created on mga6.

Yes AFAIK passwordless users have always worked at least for Mandriva&Mageia KDE

User created during *mga6 install* without password (network boot iso last week) *can* log in.  But not passwordless users created from MCC later.

I meant login AND unlock.

ok so i did more tests today.


userdrake   test  => User created with useradd but inactive ( i removed the ! in /etc/shadow )
        => lock / unlock    OK

userdrake   testmcc  => User created with mcc
        => lock / unlock    NOK

Assigning to the Mageia Tools maintainer group rather than specifically Thierry Vignaud.

Assignee: thierry.vignaud => mageiatools

The user has succeed to login with the Plasma stack which then fails on the lock screen.

Source RPM: userdrake => plasma-workspace, userdrake

(In reply to Thierry Vignaud from comment #16)
> I doubt that's a pam issue if it works for some users and not for others...
> You should compare their entries in /etc/{passwd,shadow}

I compared the behavior of mga5 and cauldron in regard to account creation and found that the behavior looks the same though only mcc/userdrake will allow the creation of a user account with a blank password that will actually work without manual intervention.

useradd will create a user which will have a blank password (if the passwd command is not used), but the account will also be locked as neoclust indicated in comment #19. You have to remove the ! in /etc/shadow to unlock the account. The passwd command will not allow a blank password. Behavior is the same on mga5 and cauldron.

Entry in /etc/passwd
uanopass:x:1002:1002::/home/uanopass:/bin/bash (via useradd)

Entry in /etc/shadow
uanopass:!:17196:0:99999:7:::  <<< must manually remove the ! to unlock)

userdrake/mcc will create a user with a blank password that is actually a hash that apparently evaluates as null on both mga5 and cauldron.

Entry in /etc/passwd
udnopass:x:1003:1003:udnopass:/home/udnopass:/bin/bash (via userdrake)

Entry in /etc/shadow
udnopass:$2a$08$qkEmRkL.5sJzCAwk3cOiYOKk0Yj7DeByeB/b/kvDc/qbumx8ZLgIS:17196::99999::::

Again, the above are the same in both mga5 and cauldron.

Log in works with both forms of /etc/shadow on both mga5 and cauldron.

Screen unlock works with both forms on mga5 but on cauldron only the useradd form works, the hash does not.

The status comment in the bug refers to userdrake but there doesn't seem to be anything visible in /etc/passwd or /etc/shadow to indicate a problem and login works with the hash on both mga5 and cauldron.

I wonder how much kscreenlocker changed in the transition from kde4 to plasma. Maybe they changed how passwords are handled in the transition?

CC: (none) => mrambo

I can reproduce the issue. I created a user named "guest" with no password using drakuser. When running this command from a shell:

/usr/libexec/kcheckpass -U guest
Password:

It's happy with no password being passed. This is compatible with the initial login form where no password lets you log in. So my guess is that /usr/libexec/kscreenlocker_greet waits for a password of length > 0 to be passed, and doesn't do anything if no password in passed, except in the case where /etc/shadow contains no hash at all:

https://github.com/KDE/kscreenlocker/blob/master/kcheckpass/checkpass_shadow.c contains:

  spw = getspnam(login);
  password = spw ? spw->sp_pwdp : pw->pw_passwd;

  if (!*password)
    return AuthOk;

  if (!(typed_in_password = conv(ConvGetHidden, 0)))
    return AuthAbort;


So if I understand this code correctly (I don't speak C or C++ at all, so forgive me if I misunderstood this code entirely), it will return AuthOk if no password is set at all in /etc/shadow, and will return AuthAbort if the user didn't pass any password, which means that this code misses the case where the empty string has been hashed (as done by drakuser).

CC: (none) => LpSolit

oh interesting.

I will report the issue upstream.

After some more investigation, my opinion is that Plasma is doing the right thing, i.e. waits for a password, and an empty password is not a password. :)

IMO, drakuser should set an empty string into /etc/shadow instead of hashing an empty string. In http://gitweb.mageia.org/software/userdrake/tree/userdrake#n504:

  $ctx->UserSetPass($userEnt, $u{passwd});

calls http://gitweb.mageia.org/software/userdrake/tree/USER/USER.xs#n202:

  Admin_UserSetPass(self, ent, userPasswd)

which contains:

  char *userPasswd
  PPCODE:
  USER__ERR *error = NULL;
  gboolean crypted = FALSE;
  if (lu_user_setpass(self, ent, userPasswd, crypted, &error) == FALSE) {

and lu_user_setpass() will do the hashing. Maybe we could set crypted to TRUE if userPasswd is empty, so that it doesn't try to hash it. I don't speak C, so I don't know how to write the check, maybe something like:

  gboolean crypted = userPasswd == '' ? TRUE : FALSE;

But then, I don't know the result of this change, so I don't know if it works. Could someone test it, please? :)

Created attachment 8985 [details]
do not encrypt the empty string, v1

I finally tested it myself. This works with both cases: with and without a password.

Status: NEW => ASSIGNED
Assignee: mageiatools => LpSolit

Please commit, it seems OK for me

commit 10841ca8e2ab3824db98113f7149b7743f98645a
Author: Frédéric Buclin <LpSolit@...>
Date:   Fri Feb 24 18:31:30 2017 +0100

    Do not encrypt the empty password (mga#19318)
---
 Commit Link:
   http://gitweb.mageia.org/software/userdrake/commit/?id=10841ca8e2ab3824db98113f7149b7743f98645a

thank you a lot

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED