Bug 19318 - Plasma screen locker fail with empty passwords => When created by userdrake
Summary: Plasma screen locker fail with empty passwords => When created by userdrake
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker normal
Target Milestone: ---
Assignee: Frédéric "LpSolit" Buclin
QA Contact:
Keywords: PATCH
Depends on:
Blocks: 17523
  Show dependency treegraph
Reported: 2016-09-09 10:38 CEST by Morgan Leijström
Modified: 2017-02-24 23:44 CET (History)
15 users (show)

See Also:
Source RPM: plasma-workspace, userdrake
Status comment: Patch for userdrake needs review

journalctl -ab from first login of fresh passwordless user test2 (19.60 KB, text/x-log)
2016-09-19 23:24 CEST, Morgan Leijström
do not encrypt the empty string, v1 (996 bytes, patch)
2017-02-24 18:35 CET, Frédéric "LpSolit" Buclin
Details | Diff

Description Morgan Leijström 2016-09-09 10:38:36 CEST
Steps to Reproduce:

1.  create a new user (I used MCC); except name simply use defaults and do not fill in password.

2. Log into Plasma as that user

3. KDE (cauldron logo) Menu > Leave > Lock

4. Try to log in; fail

I dont know if it have been like this always on cauldron/plasma, but at least a month.

It always have worked on KDE on Mageia 5 and earlier, and also still on cauldron in other DE.
Morgan Leijström 2016-09-09 10:48:12 CEST

Assignee: bugsquad => kde

Comment 1 Rémi Verschelde 2016-09-09 10:51:30 CEST
Setting as release blockers for now as having empty passwords should be supported.

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

Comment 2 Rémi Verschelde 2016-09-09 10:58:15 CEST
It might also be worth reporting upstream (bugs.kde.org) in parallel to this issue.
Comment 3 Nicolas Lécureuil 2016-09-09 11:01:16 CEST
no, we will test and ask for a report if this is an upstream issue.

CC: (none) => mageia

Comment 4 David Walser 2016-09-09 15:08:31 CEST
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.
Comment 5 Nicolas Lécureuil 2016-09-18 09:17:29 CEST
I just tested on a fresh cauldron and i can't reproduce.

May this be an upgrade issue ?

Ever confirmed: 1 => 0

Comment 6 Nicolas Lécureuil 2016-09-19 11:41:51 CEST
is this bug still valid for you with plasma 5.8 Beta ?
Comment 7 Morgan Leijström 2016-09-19 23:21:37 CEST
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
Comment 8 Morgan Leijström 2016-09-19 23:24:40 CEST
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.
Comment 9 Morgan Leijström 2016-09-19 23:35:35 CEST
@#7: s/patters/matters

.xsession-errors in that user home is zero bytes !
Comment 10 Nicolas Lécureuil 2016-09-22 16:29:32 CEST
i will do a mga 5 to 6 update to test then.
Comment 11 Nicolas Lécureuil 2016-10-05 12:46:11 CEST
i still dont reproduce. 
Can someone else reproduce the issue ?
Comment 12 Morgan Leijström 2016-10-05 13:18:37 CEST
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!
Comment 13 Morgan Leijström 2016-10-05 13:42:34 CEST
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
Comment 14 Nicolas Lécureuil 2016-10-05 17:21:03 CEST
ok i reproduce now. 
Seems a pam issue as it works with user created on mga5 but not on users created on mga6.

Ever confirmed: 0 => 1

Marja Van Waes 2016-10-07 11:53:48 CEST

See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=19536

Comment 15 Marja Van Waes 2016-10-07 11:57:53 CEST
(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?

Comment 16 Thierry Vignaud 2016-10-07 12:52:01 CEST
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}
Comment 17 Morgan Leijström 2016-10-07 13:12:56 CEST
(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.
Comment 18 Morgan Leijström 2016-10-07 13:14:11 CEST
I meant login AND unlock.
Comment 19 Nicolas Lécureuil 2016-10-29 21:47:41 CEST
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
Nicolas Lécureuil 2016-11-06 15:42:06 CET

Assignee: kde => thierry.vignaud
Summary: Plasma screen locker fail with empty passwords => Plasma screen locker fail with empty passwords => When created by userdrake

Comment 20 Samuel Verschelde 2016-11-08 11:26:47 CET
Assigning to the Mageia Tools maintainer group rather than specifically Thierry Vignaud.

Assignee: thierry.vignaud => mageiatools

Samuel Verschelde 2016-11-08 12:34:48 CET

Status comment: (none) => Needs a fix in userdrake, probably.
Source RPM: plasma-workspace-5.7.4-2.mga6.src.rpm, pam? => userdrake

Comment 21 Thierry Vignaud 2017-01-16 11:30:20 CET
The user has succeed to login with the Plasma stack which then fails on the lock screen.

Source RPM: userdrake => plasma-workspace, userdrake

Comment 22 Mike Rambo 2017-01-30 21:32:40 CET
(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

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

Comment 23 Frédéric "LpSolit" Buclin 2017-02-23 03:53:41 CET
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

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

Comment 24 Nicolas Lécureuil 2017-02-23 09:24:29 CET
oh interesting.

I will report the issue upstream.
Comment 25 Frédéric "LpSolit" Buclin 2017-02-24 15:00:28 CET
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
  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? :)
Comment 26 Frédéric "LpSolit" Buclin 2017-02-24 18:35:09 CET
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.

Assignee: mageiatools => LpSolit

Frédéric "LpSolit" Buclin 2017-02-24 18:35:51 CET

Status comment: Needs a fix in userdrake, probably. => Patch for userdrake needs review

Marja Van Waes 2017-02-24 21:47:10 CET

Keywords: (none) => PATCH
CC: (none) => mageiatools

Comment 27 Nicolas Lécureuil 2017-02-24 23:11:52 CET
Please commit, it seems OK for me
Comment 28 Mageia Robot 2017-02-24 23:39:56 CET
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:
Comment 29 Nicolas Lécureuil 2017-02-24 23:44:41 CET
thank you a lot

Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.