Funny enough, right after doing a Mageia 5 install without problems adding an additional user, when I repeated the process on different partitions, the user seemed to be added, but the account was "Expired" and unusable.

The error in the console was:

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

The second time I had first updated the system and then added the user.

After rebooting the new user was still unusable and setting a password still didn't work, to fix this I used:
 
  userdel <username>
  groupadd -g <GID> <username>
  useradd -g <GID> -u <UID> <username>
  passwd <username>

and now everything works fine for that user.

However, again trying to add a new user in MCC does again give

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

And again the account has status "Expired" :-/

David, Sophie says you were the last one to touch libuser, do you have any ideas?

CC: (none) => luigiwalser, marja11

The libuser security update changed its tools that manipulate /etc/passwd and related files to use the correct locking scheme that they should have been using all along, according to RedHat's documentation on the update.  Maybe MCC is expecting it to still work incorrectly and needs to be updated to cope with the locking scheme.

Either that or libuser is really broken (it shouldn't be though).  Does it have its own command-line tools for user creation that you can test (to rule out MCC)?

(In reply to David Walser from comment #2)
> The libuser security update changed its tools that manipulate /etc/passwd
> and related files to use the correct locking scheme that they should have
> been using all along, according to RedHat's documentation on the update. 
> Maybe MCC is expecting it to still work incorrectly and needs to be updated
> to cope with the locking scheme.

CC'ing tv
> 
> Either that or libuser is really broken (it shouldn't be though).  Does it
> have its own command-line tools for user creation that you can test (to rule
> out MCC)?

I can't find them, but "man libuser.conf" is about "configuration for libuser and libuser utilities", so maybe one of those "libuser utilities" could create users and groups?

Also CC'ing doktor5000, because he's much better at googling than I am

Summary: Update of libuser causes regression in mcc => Update of libuser causes regression in mcc ('Invalid contents of lock `/etc/shadow.lock'')

(now really CC'ing)

CC: (none) => doktor5000, thierry.vignaud

The problem does _not_ exist when using 

   adduserdrake

there is no error message, and it is perfectly possible to log in with the newly created user. :-D

However, _userdrake_ fails

rpm -ql libuser

shows that it does have some of its own commands, like luseradd and equivalents for many others.  Do these work correctly?

[root@localhost marja]# luseradd twee
Account creation failed: Invalid contents of lock `/etc/shadow.lock'.
[root@localhost marja]#

We should try updating to 0.62, which is what Fedora is doing, to see if it's better.  In 0.61, they added Python3 support.  Philippe, can you help with this update?

CC: (none) => makowski.mageia

(In reply to David Walser from comment #8)
> In 0.61, they added Python3 support.  Philippe, can you help
> with this update?

ok will try to see if 0.61 can help with Python3, but I also see that "The current libuser version is 0.62"
https://fedorahosted.org/libuser/browser/NEWS?rev=libuser-0.62

(In reply to Philippe Makowski from comment #9)
> (In reply to David Walser from comment #8)
> > In 0.61, they added Python3 support.  Philippe, can you help
> > with this update?
> 
> ok will try to see if 0.61 can help

oups typo :  0.62 of course

information with : libuser-0.60-5.1.mga5

# LC_ALL=C luseradd test
Account creation failed: Invalid contents of lock `/etc/shadow.lock'.
but the user is created

with libuser-0.62-1.mga5.x86_64 I get the same result
I tried to build Python3, but with no success.


So instead of the Fedora patch to 0.60 I took the OpenSUse patch
https://build.opensuse.org/package/show/security:SELinux/libuser

I built a libuser-0.60-5.2.mga5 with this patch and now :
$ LC_ALL=C luseradd test
$ LC_ALL=C luserdel test2
User test2 does not exist.
$ LC_ALL=C luserdel test
$

now problem.

So I push this update to testing (it have code ready for Python3 if need, and if it want to build in the future)

Feel free to push it to cauldron

packages :
lib(64)ser1-0.60-5.2.mga5
libuser-0.60-5.2.mga5
libuser-ldap-0.60-5.2.mga5
lib(64)user-devel-0.60-5.2.mga5
libuser-debuginfo-0.60-5.2.mga5
libuser-python-0.60-5.2.mga5

From
libuser-0.60-5.2.mga5.src.rpm

Thanks...

I don't understand how this fixed it though, unless the Blowfish patch was the reason for the problem.  It looks like the CVE patch you removed and the OpenSuSE one you added are the same.

(In reply to David Walser from comment #12)
> Thanks...
> 
> I don't understand how this fixed it though, unless the Blowfish patch was
> the reason for the problem.  It looks like the CVE patch you removed and the
> OpenSuSE one you added are the same.
you are right, it was the Blowfish patch the problem
sorry for my bad explanation, I did so much tries that I forgot this one.
I don't understand why we where using this patch.
Seems that it was imported from Mandriva.

There does not seem to be a lib64ser1 package. Is that the correct name?


The updated package libuser-0.60-5.2.mga5 does not work for me.
I get a "Login Failed" message when trying to login to the new user.

The user is _not_ expired
A home directory is created
The entry in /etc/password seems OK

However, the entry in /etc/shadow looks abnormal. It is twice as long as the other entries for normal users.

Changing the password of an existing user results in a login failure for that user, with a similar odd looking entry in /etc/shadow.

Using adduserdrake does work. It creates an /etc/shadow entry that looks normal.

I've just realised that lib(64)ser1 should be lib(64)user1, which was updated  automatically when I updated libuser.

I confirm that the update candidate makes it possible to create users, but I can't login into the new user with KDM.

I created a user using "luseradd -P". It creates the user but it is not possible to login. The /etc/shadow entry created is "abnormal", being extremely long.

Using passwd to change the password, creates a normal looking entry in /etc/shadow and makes it possible to login. Using lpasswd to again change the password results again in an abnormal /etc/shadow entry and makes it impossible to login.

Does this help to locate the cause of the problem?

reason is simple before this update we had a Blowfish patch

# default to blowfish for passwords instead of md5 (#59158)
Patch1:                libuser-0.57.1-blowfish.patch

--- libuser-0.56.15/libuser.conf~       2010-03-04 17:44:57.000000000 +0100
+++ libuser-0.56.15/libuser.conf        2010-05-18 13:36:00.000000000 +0200
@@ -17,7 +17,7 @@ default_useradd = /etc/default/useradd
 # skeleton = /etc/skel
 # mailspooldir = /var/mail
 
-crypt_style = sha512
+crypt_style = blowfish
 modules = files shadow
 create_modules = files shadow
 # modules = files shadow ldap

if we let this patch, then after the security fix for CVE-2015-3245 and CVE-2015-3246 (https://bugs.mageia.org/show_bug.cgi?id=16459) lead to the first regression reported in this bug report, if we remove the patch, we don't have the initial regression reported here, but the new one. in fact the security fix don't like crypt_style = blowfish, but if we go to defaut crypt_style = sha512 , the we have old users crypted with blowfish, and new one with sha512.

we have to rewrite the security patch if we want to keep blowfish or we have to convert  blowfish to sha512 

here the situation, but I don't know what to do

I'd suggest we rewrite the blowfish patch on top of the others as it's likely that the CVE patches are likely to be integrated as it in next release, so we'll have to do that rebase part at some time.

Also, we should considerate migrating to stronger hashes in mga6 (like FC did)

CC: (none) => tmb

well, sha512 is not stronger than blowfish, only different.

But it's managed by default thus no more need for us to keep patches in mga7

This is likely to be affecting new installs, so we need to prioritise it.

(In reply to claire robinson from comment #23)
> This is likely to be affecting new installs

As demonstrated by this post in the forum:
https://forums.mageia.org/en/viewtopic.php?f=7&t=10103

Mageia 4 is also affected.
https://forums.mageia.org/en/viewtopic.php?f=8&t=10111

Whiteboard: MGA5TOO feedback => MGA5TOO MGA4TOO feedback
Source RPM: libuser-0.60-5.1.mga5 libuser-0.60-6.mga6 => libuser-0.60-5.1.mga5 libuser-0.60-6.mga6 libuser-0.60-2.1.mga4

(In reply to Thierry Vignaud from comment #22)
> But it's managed by default thus no more need for us to keep patches in mga7

yes, and seems that Debian, Fedora, Opensuse are using default, seems that Mageia is using blowfish only because Mandriva was using blowfish.
libuser in Fedora moved to sha512 in 2010 http://pkgs.fedoraproject.org/cgit/libuser.git/commit/?id=585e2be200597f3bd64887f466dcbfabc2294d07

We could start by dropping libuser-0.57.1-blowfish.patch
Thus new users would and/or users with updated passwords would switch to sha512 passwrods...
That would reduce the damage.

Then some couragous lad should try to lookup which change in the big intrusive CVE patch is breaking blowfish

Note than running one of the broken commands under valgrind could help pinpoint the issue...

Let's also CC: Pascal which is the one that did the blowfish patch in the first place ("fix blowfish encoding" in 2010)

CC: (none) => pterjan

And if we drop the patch defaulting to blowfish, it looks like there's no issue?
(according to Philippe in Comment #18)
If that's the case, let's just drop this patch.
Then in mga7, we can drop the other blowfish patch.

For the /etc/shadow.lock error, we just need to kill that file on update with a trigger.
After the CVE fix, libuser writes its PID into it whereas the old lock file was empty.
Thus we just need to nuke it on update...

(In reply to Thierry Vignaud from comment #30)
> And if we drop the patch defaulting to blowfish, it looks like there's no
> issue?
there is an issue, shadow mix blowfish and sha512 so it lead to comment #16 and #14

(In reply to Thierry Vignaud from comment #31)
> For the /etc/shadow.lock error, we just need to kill that file on update with a trigger.

if you think it is the solution, then revert to what was libuser-0.60-5.1.mga5.src.rpm but add the trigger trick

and for cauldron switch to default sha512, but we need to handle the change from blowfish to sha512 (and fix the python3 build, but that another story)

(In reply to Thierry Vignaud from comment #29)
> Let's also CC: Pascal which is the one that did the blowfish patch in the
> first place ("fix blowfish encoding" in 2010)

It seems I did a patch to fix blowfish usage, which was a different patch from the one switching the default.
The package has 2 patches, one to change the default (by oden it seems) and one to make it work (by me it seems even if I don't remember).

I am confused by all mentions of "the blowfish patch" in this bug.

I've removed the patch defaulting to blowfish instead of SHA512 & I've added a trigger for killing the old format lock file (they really fscked upstream, they should have handled that case :-( )
(if someone wants to submit upstream a patch for that, feel free, else the trigger is fine with me)

So what do we do for mga5 and mga4 ?

bring back libuser-0.60-5.1.mga5 and add the trigger that Thierry added to cauldron ?
by bring back I mean keep the patch defaulting to blowfish instead of SHA512

add the trigger that Thierry added to cauldron libuser-0.60-2.1.mga4 ?

Note that I've _removed_ this patch in cauldron.
I don't think it's wise to resurrect it.

So do we need to fix USER.pm?

(In reply to Thierry Vignaud from comment #36)
> Note that I've _removed_ this patch in cauldron.
> I don't think it's wise to resurrect it.

That's why I'm asking
so mga4 default blowfish
cauldron default sha512
mga5 default sha512

but for mga5, this will lead to have old users with blowfish and new ones with sha512, would it be ok to mix both ? any other tools impacted ? 
(comment #36)
>So do we need to fix USER.pm?
yes what about USER.pm ?

I have some crashes in manauser, i've fixed some in git but i have no time to
provide a fixing in mga5 and i would like to understand if i have to change the
code or not because something has changed before testing undefined values
here and there....

(In reply to Thierry Vignaud from comment #36)
> Note that I've _removed_ this patch in cauldron.
> I don't think it's wise to resurrect it.

so in cauldron you also need to change /etc/login.defs in shadow-utils I guess
to have something like :

ENCRYPT_METHOD SHA512 

instead of 

CRYPT_PREFIX $2a$

no ?

For Mageia 5, I added the trigger, and kept the blowfish default. Seems that this fix our issues.

please test :

packages :
lib(64)user1-0.60-5.3.mga5
libuser-0.60-5.3.mga5
libuser-ldap-0.60-5.3.mga5
lib(64)user-devel-0.60-5.3.mga5
libuser-debuginfo-0.60-5.3.mga5
libuser-python-0.60-5.3.mga5

From
libuser-0.60-5.2.mga5.src.rpm

If it is ok, same can be done in Mageia4


For cauldron see my previous comment #c40

On mga-5-64, I installed the latest packages from testing:

urpmi --search-media "Core Updates Testing" libuser lib64user1

installing lib64user1-0.60-5.3.mga5.x86_64.rpm libuser-0.60-5.3.mga5.x86_64.rpm 

Using drakuser I can create, edit and delete users. I can login to new and edited user accounts.

So far as I can tell these packages fix the problem.

mga5 32 LANG=fr_FR.UTF-8

libuser1-0.60-5.3.mga5.i586.rpm
libuser-0.60-5.3.mga5.i586.rpm

before update :
drakuser -> create user -> Invalid contents of lock `/etc/shadow.lock'
user created but not homedir.

after update :
drakuser -> create user -> ok.
drakuser -> delete user -> ok.

Whiteboard: MGA4TOO feedback MGA5-64-OK => MGA4TOO feedback MGA5-64-OK MGA5-32-OK
CC: (none) => yann.cantin

Thanks Philippe.  Please remove the feedback marker from the whiteboard once you build the update for Mageia 4.

Works ok here too nice job to get this fixed thx. :)

CC: (none) => otto.leipala

For Mageia 4 :

packages :
lib(64)user1-0.60-2.2.mga4
libuser-0.60-2.2.mga4
libuser-ldap-0.60-2.2.mga4
lib(64)user-devel-0.60-2.2.mga4
libuser-debuginfo-0.60-2.2.mga4
libuser-python-0.60-2.2.mga4

From
libuser-0.60--2.2.mga4.src.rpm

Whiteboard: MGA4TOO feedback MGA5-64-OK MGA5-32-OK => MGA4TOO MGA5-64-OK MGA5-32-OK

Thanks Philippe. Was there also a final fix pushed to cauldron?

Cauldron is fine AFAIK

(In reply to Thierry Vignaud from comment #48)
> Cauldron is fine AFAIK

you changed also shadow-utils to default to SHA512 ?

Testing on mga4-64

rpm -q libuser
libuser-0.60-2.1.mga4
Confirmed that the bug exists - new user created with "expired" status 
and home directory not created.

Installed updates from testing:

urpmi --search-media "Core Updates Testing" libuser lib64user1                   
ftp://192.168.0.2//pub/mirror/Mageia/distrib/4/x86_64/media/core/updates_testing
/lib64user1-0.60-2.2.mga4.x86_64.rpm 
ftp://192.168.0.2//pub/mirror/Mageia/distrib/4/x86_64/media/core/updates_testing
/libuser-0.60-2.2.mga4.x86_64.rpm           
installing libuser-0.60-2.2.mga4.x86_64.rpm lib64user1-0.60-2.2.mga4.x86_64.rpm 
from /var/cache/urpmi/rpms

Creation, deletion and editing of users all OK

OK for mga-4-64

Whiteboard: MGA4TOO MGA5-64-OK MGA5-32-OK => MGA4TOO MGA5-64-OK MGA5-32-OK MGA4-64-OK

Testing on mga-4-32

Confirmed that the bug exists
rpm -q libuser
libuser-0.60-2.1.mga4
New user created with "expired" status and no home directory

Installed updates from testing

urpmi --search-media "Core Updates Testing" libuser libuser1
ftp://192.168.0.2//pub/mirror/Mageia/distrib/4/i586/media/core/updates_testing/
libuser-0.60-2.2.mga4.i586.rpm   
ftp://192.168.0.2//pub/mirror/Mageia/distrib/4/i586/media/core/updates_testing/
libuser1-0.60-2.2.mga4.i586.rpm              
installing libuser1-0.60-2.2.mga4.i586.rpm libuser-0.60-2.2.mga4.i586.rpm from 
/var/cache/urpmi/rpms

Creation, deletion and editing of users all OK
 
OK for mga-4-32

Whiteboard: MGA4TOO MGA5-64-OK MGA5-32-OK MGA4-64-OK => MGA4TOO MGA5-64-OK MGA5-32-OK MGA4-64-OK MGA4-32-OK

Suggested Advisory
=======================
Updated libuser packages fix regressions in drakuser

The recent security update for libuser caused regressions in drakuser
(the Mageia tool for managing users on the system):
New users were created with an "expired" status
Editing a user account would result in an error message:
"Invalid contents of lock '/etc/shadow.lock"

This update restores proper functioning to drakuser

References:
https://bugs.mageia.org/show_bug.cgi?id=16467
http://advisories.mageia.org/MGASA-2015-0278.html
http://doc.mageia.org/mcc/5/en/content/userdrake.html
===========================================
Source RPMs:
libuser-0.60-2.2.mga4
libuser-0.60-5.2.mga5

The update is now validated.

A qa-committer needs to upload the advisory to SVN

The update can then be pushed to updates

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

(In reply to Philippe Makowski from comment #49)
> you changed also shadow-utils to default to SHA512 ?

err, no...

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0087.html

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

valid for Cauldron Mageia6

Status: RESOLVED => REOPENED
CC: (none) => westel
Resolution: FIXED => (none)

oops: libuser-0.60-8.mga6

Please open a new bug report, the cause might be different, and even if it's the same we can't handle it in a bug report that was already used to validate an update candidate.

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

Better to add to bug #16668 (and perhaps modify the subject line of that bug). That bug is about the same problems (but in cauldron) as this bug.

Today i' ve bitten by this bug on my Cauldron machine. Neither guest account nor newly created user can login. Guest and new user are in "Expired" status and i get same error message on terminal with userdrake:

> [atilla@tarakbumba ~]$ userdrake
> Ignore the following Glib::Object::Introspection & Gtk3 warnings
> Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.22.0/Gtk3.pm line 525.
> Hesap oluÅturma iÅlemi baÅarısız oldu: 'Invalid contents of lock `/etc/shadow.lock''.

Installed rpms related this issue:

userdrake-2.10-5.mga6
lib64user1-0.62-2.mga6

Status: RESOLVED => REOPENED
CC: (none) => tarakbumba
Resolution: FIXED => (none)

Ooopss. Sorry, i missed that this is an advisory bug report. Closing and adding comment to bug #16668

Status: REOPENED => RESOLVED
Version: 5 => Cauldron
Resolution: (none) => FIXED