This looks very similar to Bug #16467 which was fixed in mga5

adduserdrake, launched from a root terminal, works in current cauldron

luseradd fails again, too: 

    Account creation failed: Invalid contents of lock '/etc/shadow.lock'

useradd works fine.

indeed, like bug 16467

(however, i haven't  updated my system since a few days because i was waiting for neoclust to finish his updates)

Assignee: bugsquad => thierry.vignaud
CC: (none) => marja11

same in fully updated system.

Btw, in https://bugs.mageia.org/show_bug.cgi?id=16467#c56 Ben said over two months ago that that bug 16467 was still valid in cauldron

I haven't seen this for a few months (as new installs have been broken for one reason or another), but when I did my experience was different.  userdrake, on first use after a fresh install, would put up a popup saying that /etc/shadow.lock was invalid, and just refuse to do anything.  If you deleted /etc/shadow.lock, all was well and you never got the error again.

I assumed that something in either package install or Summary->User Management was erroneously leaving the file around.

CC: (none) => ftg

(In reply to Marja van Waes from comment #2)
> 
> useradd works fine.
> 

Yes it does *appear* to, using:

useradd -m -U username
passwd username

but here it's impossible to log in as the new user either at RL3 or in sddm.

The result is the same using the workaround in comment #1.

CC: (none) => zen25000

(In reply to Barry Jackson from comment #5)
> (In reply to Marja van Waes from comment #2)
> > 
> > useradd works fine.
> > 
> 
> Yes it does *appear* to, using:
> 
> useradd -m -U username
> passwd username
> 
> but here it's impossible to log in as the new user either at RL3 or in sddm.
> 
> The result is the same using the workaround in comment #1.

I gave the created users the name of the tool I used to create them (because I get too confused when creating users test1-test4), so I did:

  # useradd useradd
  # passwd useradd

etc. 

I can login with users "useradd" and "adduserdrake", both in a 32bit and a 64bit up-to-date cauldron. luseradd and userdrake fail on both arches (the created users having expired)

Hardware: x86_64 => All

(In reply to Frank Griffin from comment #4)
> I haven't seen this for a few months (as new installs have been broken for
> one reason or another), but when I did my experience was different. 
> userdrake, on first use after a fresh install, would put up a popup saying
> that /etc/shadow.lock was invalid, and just refuse to do anything.  If you
> deleted /etc/shadow.lock, all was well and you never got the error again.
> 
> I assumed that something in either package install or Summary->User
> Management was erroneously leaving the file around.

Yeah, that message still appears when starting userdrake from cli, but the desired user is created anyway (but expired).
After removing /etc/shadow.lock (which is empty, anyway) the then created user is no longer expired, but his password doesn't work :-/

I see the explanation.  Others are adding users or editing passwords.  I add my users during install summary, and was only using drakuser to tweak group memberships.

This problem still exists in latest Cauldron

This IMHO should be a release blocker.

I also notice that the suggested UID for a new user in userdrake is still 500.

Priority: Normal => release_blocker
Severity: normal => major

*** Bug 18641 has been marked as a duplicate of this bug. ***

still valid.

With the classical 64bit iso that was available for QA this afternoon, after installing and rebooting into the fresh install, the first then created user was expired again.

After removing the empty /etc/shadow.lock file and removing the expired user, adding her again worked fine.

The lockfile had a time stamp from before starting userdrake, and even from before the beginning of my journalctl logs:

[root@localhost u]# ls -al /etc/ | grep shadow
-r--r-----   1 root shadow    729 jun 21 21:52 gshadow
-r--r-----   1 root shadow    718 jun 21 21:52 gshadow-
-rw-r-----   1 root shadow   5396 feb 12 20:48 login.defs
-r--r-----   1 root shadow    980 jun 21  2016 shadow
-r--r-----   1 root shadow    898 jun 21  2016 shadow-
-rw-------   1 root root        0 jun 21 21:04 shadow.lock
[root@localhost u]#

The journalctl logs begin over half an our later than the shadow.lock file was created:
-- Logs begin at di 2016-06-21 21:38:20 CEST

So it seems the empty lock file is created during install.

I'll try to remember to check that during next install

Keywords: (none) => 6sta1
Summary: Userdrake creates expired users => Userdrake creates expired users, it seems an empty shadow.lock file is created during Mageia install
CC: (none) => makowski.mageia

I'm not sure if this should be included here, if not let me know and I'll create a new bug report.

I did a fresh install of Mga6 Dev1 ISO with Plasma5 & Mate installed, after it was available. I installed it on it's own partition and I have a /home partition and did not wipe it.

June 16 when I noticed this: 
Current users saptech & debbie work fine. I have a second user and I tried to sign into the account, but it wouldn't let me. I thought maybe I had the wrong password, so I tried to give it a new password with the passwd command as root and I get this message, "passwd: Unknown user name 'speden'".

Using MCC, Users & Groups, I added a new user and things are screwed up with it. First off, it show the new user account as expired. When I changed it and refreshed the window, it went back as expired. Two users are showing as expired.

I thought maybe a reboot would solve it after removing the expiration but it went back showing as expired.

Below is showing how /home users are listed, The new users I tried to create are speden2 & stevep. The other users are from using Mga5.

$ ls -l /home
total 36
drwx------ 28 debbie  debbie   4096 Jun 16 17:54 debbie/
drwxr-xr-x  5 saptech saptech  4096 Mar 22  2015 live/
drwx------  2 root    root    16384 Mar 20  2015 lost+found/
drwxr-xr-x 59 saptech saptech  4096 Jun 24 19:20 saptech/
drwx------ 34 speden2 speden2  4096 May 12 09:43 speden/
drwx------ 25 stevep  stevep   4096 Dec 24  2015 thekids/


# ls -al /etc/ | grep shadow
-r--r-----   1 root shadow    813 Jun 17 19:29 gshadow
-r--r-----   1 root shadow    801 Jun 17 19:29 gshadow-
-rw-r-----   1 root shadow   5396 Feb 12 13:48 login.defs
-r--r-----   1 root shadow   1076 May 16 18:13 shadow
-r--r-----   1 root shadow   1055 May 13 12:39 shadow-
-rw-------   1 root root        0 May 13 12:39 shadow.lock

CC: (none) => saptech

07.04.16
After installing Magiea-6-sta1-live-dvd install, not able to log into a second user account using the Switch User feature. At the sddm screen get login failed message. Two old users, Debbie & speden, both show as 'expired' and changing the 'Expire date' doesn't make a difference.

# ls -l /home
total 36
drwx------ 28 debbie  debbie  4096 Jul  3 17:29 debbie/
drwxr-xr-x 17 saptech live    4096 Jul  3 22:35 live/
drwx------  2 root    root   16384 Mar 20  2015 lost+found/
drwxr-xr-x 60 saptech live    4096 Jul  4 08:47 saptech/
drwx------ 34 speden  speden  4096 May 12 09:43 speden/
drwx------ 25    1003   1003  4096 Dec 24  2015 thekids/


# ls -al /etc/ | grep shadow
-r--r-----   1 root shadow    810 Jul  3 23:38 gshadow
-r--r-----   1 root shadow    803 Jul  3 23:38 gshadow-
-rw-r-----   1 root shadow   5396 Feb 12 13:48 login.defs
-r--r-----   1 root shadow   1025 Jul  3 22:51 shadow
-r--r-----   1 root shadow    962 Jul  3 22:51 shadow-
-rw-------   1 root root        0 Jun 29 08:44 shadow.lock

Stephen, i guess you can still log into at least one account?

Do that and edit one of the account (i.e just change the real uesrs name). Do you get a pop-up saying something like "Invalid contents of lock `/etc/shadow.lock'"

Can you then simply as root delete that file, and does it then work?
Edit user, save, log out. log in as that user?


that worked for me;

I today installed the official sta1:

The user created during install works.

- and at this time i did an full system update, then made new users -

But users created in userdrake could not log in.

back in userdrake i see user is disabled and when i try edit the user i get that "Invalid contents of lock `/etc/shadow.lock'"

Deleted that file and i could edit user and now he can log in.

CC: (none) => fri

From #mageia-qa
 <marja> hi, is there anyone around who did a recent sta1 install and did *neither* create a new user *nor* change a user or root password? .... Could you please check whether there's a /etc/shadow.lock file in your install?


I made a clean install using boot.iso yesterday
I have not added any users (other than the one created during installation) nor changed any password
I have:
ls -ll /etc/shadow.lock
-rw------- 1 root root 0 Jul  7 13:32 /etc/shadow.lock

CC: (none) => jim

(In reply to James Kerr from comment #16)

> 
> 
> I made a clean install using boot.iso yesterday
> I have not added any users (other than the one created during installation)
> nor changed any password
> I have:
> ls -ll /etc/shadow.lock
> -rw------- 1 root root 0 Jul  7 13:32 /etc/shadow.lock

Shlomi found a /etc/shadow.lock file, too:

2016:07:08:19:33 < rindolf> marja: ok, I install Xfce.
2016:07:08:19:47 < rindolf> marja: there is an /etc/shadow.lock file after installation on mgav6sta1/classic-dvd/x86-64/Xfce

Thanks, James and Shlomi :-)

Adjusting the summary

Summary: Userdrake creates expired users, it seems an empty shadow.lock file is created during Mageia install => Userdrake creates expired users because an empty shadow.lock file was created during Mageia install
CC: (none) => shlomif

FWIW the timestamp on /etc/shadow.lock indicates that it was created very early during the installation.

(In reply to James Kerr from comment #18)
> FWIW the timestamp on /etc/shadow.lock indicates that it was created very
> early during the installation.

Even before the setRootPassword_addUser step?

I found two ways to create empty /etc/shadow.lock files in an installed system: 1. just running adduserdrake and adding a user
2. running useradd to add a user

(There is no problem with userdrake, nor with luseradd)

IIUC, in the setRootPassword_addUser step useradd is used.

So it seems that useradd is the culprit.

Unfortunately, useradd (provided by shadow-utils) has no maintainer :-(

Reassigning to pkg-bugs@ml

CC: (none) => ennael1, thierry.vignaud, tmb
Assignee: thierry.vignaud => pkg-bugs
Source RPM: userdrake-2.10-5.mga6 => shadow-utils-4.2.1-8.mga6

Morgan Leijström, I tried your suggestions and did not work. I keep getting login failed for users debbie & speden. I can log in as saptech, my first & main user. I also deleted the lock file, and still will not let other users log in (login failed).

ls -al /etc/ | grep shadow
-r--r-----   1 root shadow    822 Jul  4 09:12 gshadow
-r--r-----   1 root shadow    810 Jul  4 09:12 gshadow-
-rw-r-----   1 root shadow   5396 Feb 12 13:48 login.defs
-r--r-----   1 root shadow   1025 Jul  3 22:51 shadow
-r--r-----   1 root shadow    962 Jul  3 22:51 shadow-

This is very strange. Using the Dev1 iso, I didn't have this problem. I wonder what would happen if I reinstall sta1 and add all the users at that point? /home is on a separate partition and I need those users data.

@ Stephen

Did you delete and recreate the users debbie & speden?

If so, can you login as debbie or speden in a VT? (so: switch to e.g. tty2 with ctrl+alt+F2 and do a text login there)

Marja van Waes, before reading your comment, I created a brand new user and it is working good. No issues.

After reading your comment, I deleted & recreated user speden. It showed as Locked and I unlocked it. A pop-up asked if I wanted to remove /home/speden, which I answered Yes, should I answer NO. But it didn't remove /home/speden. 

I rebooted and logged in as saptech and switched to tty2, signed in as speden, but it went straight to the user prompt ($). It didn't ask for a password, even though I gave it one, this is how I could see the pop-up didn't remove /home/speden. 

I didn't do anything with user debbie yet. debbie & speden was showing 'expired' and while in MCC's User & Groups the expired date show 2016.02.09 and if I change it to a future date, they always revert back to that past date. After recreating speden, I was able to change the expired date to a future date. Year 2020.

@ Stephen

Can you please ask for help in the forums and post the link to that forums thread here?

Summary: Userdrake creates expired users because an empty shadow.lock file was created during Mageia install => An empty shadow.lock file is created during Mageia install, blocking later usage of userdrake or luseradd. Adduserdrake and useradd create an empty shadow.lock file, too

(In reply to Marja van Waes from comment #19)
> (In reply to James Kerr from comment #18)
> > FWIW the timestamp on /etc/shadow.lock indicates that it was created very
> > early during the installation.
> 
> Even before the setRootPassword_addUser step?
> 

Yes.

I've just completed a clean installation, using boot.iso and have:

# ls -ll /etc/shadow.lock
-rw------- 1 root root 0 Jul  9 20:09 /etc/shadow.lock

and 

# ls -ll /etc/shadow
-r--r----- 1 root shadow 956 Jul  9 20:54 /etc/shadow

The time stamp on /etc/shadow corresponds with the time that I had recorded as when the superuser and first user were created.

It may be just coincidence, but I also have:

# rpm -qa --last | grep lib64user
lib64user1-0.62-4.mga6.x86_64                 Sat 09 Jul 2016 20:08:21 BST

That is just seconds before /etc/shadow.lock was created.

I also have:

$ rpm -qa --last | grep shadow-utils
shadow-utils-4.2.1-8.mga6.x86_64              Sat 09 Jul 2016 20:09:52 BST

With Mageia-6-sta1 Plasma 5.7.0 on non-EFI non-GPT real h/w nVidia desktop, I cannot get a 2nd user to login.
   Its entry in the MCC user table is marked 'Expired'.

(Tried changing the expiry date to decades later, then reboot, but still 2nd user login fails.)

Show stopper?

CC: (none) => maurice

(In reply to Maurice Batey from comment #26)

> Show stopper?

Yes.
This bug report was set to "Release Blocker" ± 1½ months ago

@ Marja, here is the link to the forum thread.

https://forums.mageia.org/en/viewtopic.php?f=15&t=11203

Thanks.

This affect to manatools/manauser too here is "upstream" bug report.

https://github.com/manatools/manatools/issues/4?_pjax=%23js-repo-pjax-container

CC: (none) => ozkyster

(In reply to James Kerr from comment #24)
> (In reply to Marja van Waes from comment #19)
> > (In reply to James Kerr from comment #18)
> > > FWIW the timestamp on /etc/shadow.lock indicates that it was created very
> > > early during the installation.
> > 
> > Even before the setRootPassword_addUser step?
> > 
> 
> Yes.
> 
> I've just completed a clean installation, using boot.iso and have:
> 
> # ls -ll /etc/shadow.lock
> -rw------- 1 root root 0 Jul  9 20:09 /etc/shadow.lock

I can confirm that, in an install I did this evening, the shadow.lock file was created at the beginning of packages install, maybe even right after the root partition was formatted.

I'm starting to wonder how that was in Mga5 installs: did it get created there, too (and maybe get removed later)?

Adding UPSTREAM keyword, because it is an upstream bug. Not that we should wait to workaround it like was managed in Mageia 5

Keywords: (none) => UPSTREAM
See Also: (none) => https://github.com/shadow-maint/shadow/issues/10, https://bugs.mageia.org/show_bug.cgi?id=16467

*** Bug 17095 has been marked as a duplicate of this bug. ***

CC: (none) => westel

I think I understand why we have a problem :
http://svnweb.mageia.org/packages/cauldron/shadow-utils/current/SOURCES/shadow-970616.login.defs?r1=657627&r2=863392

but we still use blowfish in libuser

all the story is coming from https://bugs.mageia.org/show_bug.cgi?id=16459
and continue here :
https://bugs.mageia.org/show_bug.cgi?id=16467

we really need to be clear ant to choose blowfish or SHA512
in my opinion, we should go to SHA512
so we need to change libuser and drop libuser-0.57.1-blowfish.patch

opinion ?

(In reply to Philippe Makowski from comment #33)
> I think I understand why we have a problem :
> http://svnweb.mageia.org/packages/cauldron/shadow-utils/current/SOURCES/
> shadow-970616.login.defs?r1=657627&r2=863392

I'm glad you understand it :-)

> 
> but we still use blowfish in libuser
> 
> all the story is coming from https://bugs.mageia.org/show_bug.cgi?id=16459
> and continue here :
> https://bugs.mageia.org/show_bug.cgi?id=16467
> 
> we really need to be clear ant to choose blowfish or SHA512
> in my opinion, we should go to SHA512
> so we need to change libuser and drop libuser-0.57.1-blowfish.patch
> 
> opinion ?

SHA512, please (reading bug 16467 I not only understand that'll be easier to maintain, but I also get the impression that there was agreement about switching to SHA512 - at least no one objected)

However, it needs someone who' knows how to do it and who has time for it.
Would you be able to?

(In reply to Marja van Waes from comment #34)
> SHA512, please (reading bug 16467 I not only understand that'll be easier to
> maintain, but I also get the impression that there was agreement about
> switching to SHA512 - at least no one objected)
> 
> However, it needs someone who' knows how to do it and who has time for it.
> Would you be able to?

done in  libuser-0.62-5.mga6 , we'll see.

(In reply to Philippe Makowski from comment #35)

> 
> done in  libuser-0.62-5.mga6 , we'll see.

Thanks, Philippe, you rock :-)

Today i create new users which fail to log in.
I have libuser-0.62-5.mga6, and users do not get locked.

Could this change be causing Bug 18930 - New users can not log in; "crypt_ra: Numerical result out of range" in log.

(In reply to Morgan Leijström from comment #37)
> Could this change be causing Bug 18930 - New users can not log in;
> "crypt_ra: Numerical result out of range" in log.

Yes

we need to change our pam package to use sha512
something like this change : http://pkgs.fedoraproject.org/cgit/rpms/pam.git/commit/?h=pam-1_1_1-4_fc13&id=e3430d85d2599cd466dd9f9334d0f8924e2106c2

Philippe, if you're working on it, can you assign the bug report to you and set it to assigned? Just so that we know :)

(In reply to Samuel Verschelde from comment #39)
> Philippe, if you're working on it, can you assign the bug report to you and
> set it to assigned? Just so that we know :)

now, I'm not, seems TV is : https://bugs.mageia.org/show_bug.cgi?id=18930

err, I'm just helping but I'll be on one week vacation soon, so you can go on

(In reply to Thierry Vignaud from comment #41)
> err, I'm just helping but I'll be on one week vacation soon

me too, tomorrow ;)

People please review and submit when ready pam and shadow-utils

Please test pam-1.3.0-2.mga6 and shadow-utils-4.2.1-9.mga6 in 
cauldron/core/updates_testing

(In reply to Philippe Makowski from comment #43)
> Please test pam-1.3.0-2.mga6 and shadow-utils-4.2.1-9.mga6 in 
> cauldron/core/updates_testing

Nice one!

Works for me :)

I created new user in userdrake and added him to two groups - rebooted and was offered the new user in sddm which opened without issue.
I then logged out and back in with my regular user.

Well done.

Probably /OT
The next full reboot still offered me both users but on typing the password for my main user it appeared that the keyboard was not working.

In fact the typed password was being entered into the hidden field for the new user which was not visible (using the Maui sddm theme).

Having switched from main user to new and back the text was entered in the correct place.

I will look for an existing bug report for this issue or create one - however best to know what may happen when testing this bug.

Created attachment 8284 [details]
the new users in /etc/shadow

I just updated to 

lib64pam0-1.3.0-2.mga6
pam-1.3.0-2.mga6 and 
shadow-utils-4.2.1-9.mga6

while I had *no* /etc/shadow.lock file on my system.

After that I created 4 new users, and named them after the tools or commands I created them with:

adduserdrake
userdrake
luseradd
useradd

*No* new shadow.lock file was created \o/\o/\o/

Unexpectedly, the users luseradd and useradd (both created without any options, so just with "luseradd luseradd" and "useradd useradd") were both locked, but easy to unlock by editing those users with userdrake.

Logging in in a VT with adduserdrake and with userdrake went as expected: I was prompted for the password, and had to give the correct password to get logged into the related home directory.

Logging in with luseradd and useradd (after I had unlocked them) was too easy: no password was asked for (see the attached part of /etc/shadow ) 
I should have tested before updating the files whether that had already changed before. Last time I ran "useradd <username>" or "luseradd bla", the created user needed a password to log in, but that was weeks ago.

The line for adduserdrake in /etc/shadow is _much_ shorter than I had expected. Shouldn't there be two "$"s with one or two characters between them at the beginning? And shouldn't that line have two slashes?

s/before updating the files/before updating the packages/

Forget what I said about (l)useradd <username>

Of course that didn't add a password!

*** Bug 18930 has been marked as a duplicate of this bug. ***

Thanks Marja for the low level testing.
I tested end user experience only (userdrake, and different DM and DE) in my post at 18930 i began this morning but got delayed in posting.
I closed that bug duplicate now; lets concentrate here.

(In reply to Morgan Leijström from comment #50)
> Thanks Marja for the low level testing.

Hmm, I shouldn't have comment while craving for a siësta :-þ

Forget everything I said about luseradd and useradd, except that useradd no longer creates an empty shadow.lock file.

> (In reply to Morgan Leijström from comment #50)
> > Thanks Marja for the low level testing.

OOPS now i realise that could read as something else than i meant.
I meant thanks for testing the fundamental effects :)

Now *I* am taking a break, to pick blackberries with my son :)

Now on a system where there is *still* an empty

     /etc/shadow.lock 

Both adduserdrake and userdrake fail:

* adduserdrake added *no* user but gave the following messages:
  adduser: existing lock file /etc/shadow.lock without a PID
  adduser: cannot lock /etc/shadow; try again later.

* userdrake added an *expired* user and gave a message:
  Account creation failed: 'Invalid contents of lock `/etc/shadow.lock''.

useradd gave the same errors as adduserdrake
luseradd the same error as userdrake

Deleting a good, unexpired user with userdrake failed with:
* User Could Not be deleted: 'Invalid contents of lock `/etc/shadow.lock''.

However, they were deleted from /etc/passwd, only not from /etc/shadow, so after deleting /etc/shadow.lock, trying to re-add them with userdrake gave:
* User already exists, please choose another User name

In the end, with /etc/shadow.lock deleted and after solving the problem with users already exising in /etc/passwd, adding users went fine with all 4 tools.

After adding them, their entries in /etc/shadow look normal in my unexperienced eyes, *except*:

adduserdrake:D7Pu7adBRTpxc:17012:0:99999:7:::

*SUMMARY*
(from a tester with little knowledge about security):

* _Without_ existing /etc/shadow.lock file adding users works as expected.
* _With_ existing /etc/shadow.lock there are still many problems 
* The entry in /etc/shadow for users created with adduserdrake seems *wrong*
  The entries created by userdrake and those created with (l)useradd + passwd
  look ok to me

Anything that uses usermod creates /etc/shadow.lock which has to be removed after each usage.

CC: (none) => bittwister2

I just runned the same tests as Marja van Waes in #46 and #53 with:

shadow-utils-4.2.1-9.mga6
libpam0-1.3.0-2.mga6
pam-1.3.0-2.mga6
userdrake-2.11-2.mga6
System installed on 2016-07-04 and regularily updated; testing repos On.

1) Upon updating I had this information displayed (last line will appear again later on):

      2/5: libpam0               ###############################
      3/5: shadow-utils          ###############################
      4/5: pam                   warning : /etc/pam.d/system-auth saved as /etc/pam.d/system-auth.rpmsave

set_tcb - switch between tcb and shadow password schemes
version: 0.7 - $Id: set_tcb 837 2008-12-16 18:59:48Z vdanen $

 * /etc/pam.d/system-auth already uses pam_unix!  Nothing to revert!

 * Changing /etc/login.defs to enable PASS_MIN_LEN for pam_unix... done

2) With existing empty /etc/shadow.lock (timestamp from juil. 14 14:36) I confirm Marja testing but for `useradd`:

~$ ls -lthr /etc/

-rw-r--r--  1 root root     48 juil. 14 02:17 issue.net
-r--r-----  1 root shadow 1019 juil. 14 14:36 shadow-
-rw-------  1 root root      0 juil. 14 14:36 shadow.lock
-rw-r--r--  1 root root   4,5K juil. 16 22:32 sddm.conf
...
-r--r-----  1 root shadow 1,1K juil. 31 14:23 shadow
-r--r-----  1 root shadow  781 juil. 31 14:29 gshadow-
-r--r-----  1 root shadow  795 juil. 31 14:29 gshadow

* ~$ sudo adduserdrake added *no* user but gave the following messages:
  > configuration error - unknown item 'PASS_MIN_LEN' (notify administrator)
  > adduser: existing lock file /etc/shadow.lock without a PID
  > adduser: cannot lock /etc/shadow; try again later.

* ~$ sudo userdrake added an *expired* user with *no home* and gave a message:
  > Account creation failed: 'Invalid contents of lock `/etc/shadow.lock''.
  Expired since 2016-02-21

* ~$ luseradd same as userdrake.

* ~$ useradd added a (locked or expired, sorry didn't note on time) user *with* home:
  drwxr-xr-x  3 useradd 4,0K juil. 31 14:23 useradd/   # single created $HOME
  Expired since 2016-02-21

~$ mv /etc/shadow.lock â /some/user/backup/place

3) Test-users deletion:

* ~$ sudo userdel -r userdrake
  > configuration error - unknown item 'PASS_MIN_LEN' (notify administrator)

* ~$ sudo userdel -r useradd
  > configuration error - unknown item 'PASS_MIN_LEN' (notify administrator)

* ~$ sudo userdel -r luseradd
  > configuration error - unknown item 'PASS_MIN_LEN' (notify administrator)

4) Test-users creation with updated pkgs and no shadow.lock

* ~$ sudo userdrake
   No issue or message, user exists and I can log in to.

* ~$ sudo luseradd -g luseradd luseradd
   same as userdrake (after I gave this user a passwd).

* ~$ sudo adduserdrake
  > configuration error - unknown item 'PASS_MIN_LEN' (notify administrator)
   User exists and I can log in.

* ~$ sudo groupadd useradd
  same message as for adduserdrake 

  ~$ sudo useradd -g useradd -G users -s /bin/bash useradd
  same as adduserdrake (after I gave this user a passwd).

*No* /etc/shadow.lock at this point.

PS: some markdown or ReST would do good in bugzilla :)

CC: (none) => tukozaki

shadow-utils-4.2.1-10.mga6 and pam-1.3.0-3.mga6 in core/updates_testing
adduserdrake from drakxtools should be updated by tv

for me there is still one bug, under cinnamon, I can't unlock a screen locked session 
in journalctl I have :
pam_unix(cinnamon-screensaver:auth): auth could not identify password

certainly something to change elsewhere.

perhaps that cinnamon-screensaver and others package that BR pam-devel need a rebuild against this new pam package.

(In reply to Philippe Makowski from comment #56)
> shadow-utils-4.2.1-10.mga6 and pam-1.3.0-3.mga6 in core/updates_testing
> adduserdrake from drakxtools should be updated by tv

pam-1.3.0-5.mga6
shadow-utils-4.2.1-11.mga6
and
libuser-0.62-8.mga6 
were pushed (in that order) 4 days ago

And this commit
http://gitweb.mageia.org/software/drakx/commit/?id=c0529b4c5858300c0bd9c94fd35540e1f105dfd6
fixed the problem with adduserdrake.


> 
> for me there is still one bug, under cinnamon, I can't unlock a screen
> locked session 
> in journalctl I have :
> pam_unix(cinnamon-screensaver:auth): auth could not identify password
> 
> certainly something to change elsewhere.
> 
> perhaps that cinnamon-screensaver and others package that BR pam-devel need
> a rebuild against this new pam package.

Did cinnamon-screensaver-3.0.0-2.mga6 that you pushed to updates_tesing fix it for you?

CC'ing joequant

CC: tmb => joequant

Practical test today on fully updated cauldron 64:
Plasma screensaver fail to unlock a newly created user if password is nothing!

1) create a new user using userdrake, leave password unset, all other default
(I was in Plasma running it from MCC if that matters)

2) log in as that user to Plasma

... wait until screen locks (about five minutes?) ...

3) try to unlock screen saver -> fail


With another user with password defined it works.

(In reply to Morgan Leijström from comment #58)
> Practical test today on fully updated cauldron 64:

Thanks for testing :-)

> Plasma screensaver fail to unlock a newly created user if password is
> nothing!

I wasn't even aware we support empty passwords... do we?

@ neoclust

WDYT, should that work?


> With another user with password defined it works.

Nice :-)

CC: (none) => mageia

My younger child (now 6 yo) have always logged in without password in Mageia, KDE.

On fully-updated 64-bit Mga6-RC Plasma login, after removing /etc/shadow.lock and adding 2nd user, was able to login to 2nd user normally, BUT first - as the user entry was 'Locked' - had to  Edit: untick the 'Lock' box for that entry.

(In reply to Maurice Batey from comment #61)
> On fully-updated 64-bit Mga6-RC Plasma login, after removing
> /etc/shadow.lock and adding 2nd user, was able to login to 2nd user
> normally, BUT first - as the user entry was 'Locked' - had to  Edit: untick
> the 'Lock' box for that entry.

With which tool had you added the 2nd user?
Had you given the new user a password?

> With which tool had you added the 2nd user?

  MCC/System/Manage-users

> Had you given the new user a password?

   Yes, of course!

Thx, Maurice :-)

(In reply to Morgan Leijström from comment #60)
> My younger child (now 6 yo) have always logged in without password in
> Mageia, KDE.

That counts as "that should work" :-)

So as far as I understand this bug is fixed (the empty shadow.lock issue), and some other issues were raised that should be moved to new bug reports, if those don't exist already.

Resolving the shadow.lock issue as FIXED.

(In reply to Morgan Leijström from comment #58)
> Plasma screensaver fail to unlock a newly created user if password is
> nothing!

@Morgan: Could you open a bug report for this, if you don't find any existing one?

(In reply to Maurice Batey from comment #61)
> On fully-updated 64-bit Mga6-RC Plasma login, after removing
> /etc/shadow.lock and adding 2nd user, was able to login to 2nd user
> normally, BUT first - as the user entry was 'Locked' - had to  Edit: untick
> the 'Lock' box for that entry.

@Maurice: I believe new users should not be locked when created, so that's likely a bug in our tools. Could you open a bug report for this if none exist already?

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

> Could you open a bug report for this if none exist

 Will look into that when I get home this weekend.
  (On slow, unreliable hotel internet connection here in Chiavari...)

I now created Bug 19318 - Plasma screen locker fail with empty passwords

For me new users are not locked.

(In reply to Rémi Verschelde from comment #32)
> *** Bug 17095 has been marked as a duplicate of this bug. ***

confirming this is no longer valid for updated: 

Mageia-6-RC-i586-DVD.iso
DATE.txt: Sat Aug 13 15:42:09 CEST 2016
md5sum:  e6f153469350ac7cce80d10d47f96222