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

in fact this bug will be solve when https://bugs.mageia.org/show_bug.cgi?id=17504 will be completely solved too
Seems that we have to set this one as a duplicate of #17504

CC: (none) => makowski.mageia

Can you try to change /etc/pam.d/system-auth ?

replace prefix=$2a$ by sha512


to get :

#%PAM-1.0

auth        required      pam_env.so
auth        sufficient    pam_tcb.so shadow nullok sha512 count=8
auth        required      pam_deny.so

account     sufficient    pam_tcb.so shadow
account     required      pam_deny.so

password    required      pam_cracklib.so try_first_pass retry=3 minlen=4  dcredit=0  ucredit=0 
password    sufficient    pam_tcb.so use_authtok shadow write_to=shadow nullok sha512 count=8
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
-session    optional      pam_systemd.so
session     required      pam_tcb.so

instead of :

#%PAM-1.0

auth        required      pam_env.so
auth        sufficient    pam_tcb.so shadow nullok prefix=$2a$ count=8
auth        required      pam_deny.so

account     sufficient    pam_tcb.so shadow
account     required      pam_deny.so

password    required      pam_cracklib.so try_first_pass retry=3 minlen=4  dcredit=0  ucredit=0 
password    sufficient    pam_tcb.so use_authtok shadow write_to=shadow nullok prefix=$2a$ count=8
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
-session    optional      pam_systemd.so
session     required      pam_tcb.so

OK I changed both places.

Interestingly then it do not even ask password but as soon as i state user name it say login failed, in login manager as well as in terminal login, even for root.

Fortunately it worked to boot in safe mood and enter root password to get to command line.

Did you try?


BTW, I *guess* this line in comment 0:
/usr/lib64/security/pam_selinux.so: cannot open shared object file: No such file or directory
is OK as i guess it just tries to see if it exist.


(Meanwhile I confirmed the bug for new users on another mga6 system that was fresh installed (not from mga5) and apparently it have worked to create additional users in mageia a month or so ago as i have more than one OK.)

In fact, there is at least another issue, Luigi found that "in the tcb package, sha512 is disabled ", and we rely on tcb, I don't know why

(In reply to Morgan Leijström from comment #3)
> OK I changed both places.
> 
can you try now to change user password to see if all is ok after ?

(In reply to Philippe Makowski from comment #4)
> In fact, there is at least another issue, Luigi found that "in the tcb
> package, sha512 is disabled ", and we rely on tcb, I don't know why

That was added by Vincent Danen long ago.
It could be removed if we run tcb_unconvert first

Now using my test laptop instead of a production system... ;)  :

On fully updated and rebooted system, with the changed /etc/pam.d/system-auth according to comment 6, i created new user, using MCC in a plasma session.

Then i selected to start another session, and current plasma session crashed !! after some blinking of screen and popup of akonadi and other things crashed. 

At login i can enter password but it is not accepted for *any* user.

Trying Ctrl-Alt-F3 to log into text terminal and trying to log in dont ask for root password, just say it failed directly after i enter username.

After reboot the same: The login manager (here lxdm) ask for password but fail, while trying to log into a console it fail without asking password.

Have you tried yourself?

(In reply to Morgan Leijström from comment #7)
> Have you tried yourself?
yes, but I have issues too, tying to find a solution, but I don't have one yet
for now, if you can, revert what I said in comment #2
sorry

@ Philippe

Assigning to you, because you're working on it, and adding pkg-bugs ml and a bunch of smart packagers who might not yet be a member of that list to the CC, in case they can help.

Feel free to reassign to pkg-bugs ml if needed.

Keywords: PATCH => (none)
Priority: Normal => release_blocker
CC: (none) => mageia, mageia, mageia, marja11, ngompa13, pkg-bugs, pterjan, tmb
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=17504
Blocks: (none) => 15527
Assignee: bugsquad => makowski.mageia
Whiteboard: (none) => NEEDHELP

here what I understand about this issue

we are using tcb, but not completely, and we build shadow utils with tcb
and now, (maybe because of glibc change, I don't know), what was working but considered as a bug by shadow utils dev, does not work anymore.
see https://github.com/shadow-maint/shadow/issues/10

so we are here with a puzzle, that imply pam, shadow utils, tcb, libuser.
all of this have to be coordinated.
in fact blowfish or md5 doesn't really matter here, even if we need to be coherent, and use every where the same.

for me what what I understand, tcb is the problem, we need to eitheir really use it, either drop it, but not partially as we do now, unless we are able to make shadow working with classical /etc/shadow, even if built with tcb enabled.

I'm pretty sure that back in mdv days, there was a package running tcb_convert on install.
I guess this got removed at some place.
I think it would be better to just drop tcb, we're the only distro "using" it without actually using it...

I've local builds to test

(In reply to Thierry Vignaud from comment #12)
> I've local builds to test

good
my attempt yesterday to build with iurt shadow utils fails 
if we have shadow utils without tcb, then we have to manage completely the change to sha512, we need to change system-auth.pamd

Created attachment 8167 [details]
pam: drop TCB support

Created attachment 8168 [details]
shadow-utils: drop TCB support

It's pam who actually set up TCB if USE_TCB is set /etc/login.defs
Which probably nobody ever does as it's not documented...
Still a trigger on uninstalling the older pam in order to call tcb_unconvert would be safer

Comment on attachment 8167 [details]
pam: drop TCB support


Hm, we should probably do a update trigger then to revert the change on sytems with something like:

set_tcb --auto --revert

(In reply to Thierry Vignaud from comment #16)
> It's pam who actually set up TCB if USE_TCB is set /etc/login.defs
> Which probably nobody ever does as it's not documented...

Actually, the set_tcb --auto --migrate should have set the needed flags, but
seems it does not enable it anymore, but that could be because of missing --tcb flag (the thing we used to do iirc)
 
> Still a trigger on uninstalling the older pam in order to call tcb_unconvert
> would be safer

Yeah, reverting changes on should be done on upgrade

Comment on attachment 8168 [details]
shadow-utils: drop TCB support

perhaps we can add --disable-tcb and --with-sha-crypt to configure ?

another point, what are we doing with the tcb code in glibc (owl patches) ?

(In reply to Philippe Makowski from comment #19)
--disable-tcb is uneeded as I've removed the BuildRequires on tcb-devel
As for --with-sha-crypt, it's already the default in configure

(In reply to Philippe Makowski from comment #20)
> another point, what are we doing with the tcb code in glibc (owl patches) ?

We can disable it at some point.
It may wait for mga7 though

I'm away for one week,

People please review (rev 1042234) and submit when ready pam and shadow-utils

note we need to replace  /etc/pam.d/system-auth
not sure I'm doing it the right way

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

Is there a safe way to test them on a production system, or is it better in vbox? :)

Advice kepp a connections open first
But seems that it ils sage sée 17504 last comment

I assumed also a third file lib64pam-1.3.0-2.mga6 is to be updated too,
so i did that.

Tested on a fresh installed system for testing: 64 bit sta1 iso + normal upgrades + the three files here + reboot ;

(removed the /etc/shadow lock.file as per the known bug in sta1, that bug is since then fixed)

Tested new users with and without password, using lightdm, lxdm, gdm, and sddm ; logging into MATE, Gnome, LXDE, Plasma (I have not tested all combinations of DM, DE and user accounts)

!! for some reason i can not log any user into Plasma using gdm, i only get a popup window "Could not start D-bus. Can you call qbus?" and clicking OK it exits back to login.   Known bug?  That is for all users, new and old.

But using sddm i can log in to Plasma OK.



Basically it works good, fresh created users works perfectly, and old users created directly after install of sta1 before any updates works too.

There seem to be some oddity on edited users (i changed user name and password):
MATE had noting in panels for one user, had to add menu button to be able to log out... could be something transient i could not repeat yet but not time to test all combinations of display managers and DE. 

Plasma: desktop is a mess of tiles of a cut-up mageiawelcome moved around, and message window "Could not start D-bus. Can you call qbus?"

MATE screen locker is unable to unlock for any user, but that seem to be a separate bug; in system log gnome-keyring-daemon say it couldnt initialize slot with master password.  Well i have not set any master password...?
I guess it is not related with this bug here.  Also, on that screen locker there is a "switch user" button, but it only give me black screen until i press something and am back then.


Also, the mageiawelcome seem not to show "[ ] Show this window at startup" for edited users. Weird.  (seen at least when logging into MATE or Plasma using sddm or gdm with old edited user)  May be another bug, something to follow up on...


Someone who have a better clue how these things work together can probably do a better targeted testing.

Compatibility with users created on sta1 seem OK until you edit them...?!
If this solution is relesed it is probably OK for fresh installs, but for upgrading a mga5 system to mga6: is it compatible with user acconts set up in mga5 so well that such acconts can be edited (name and/or pwd) and still fully works?

Bottom line:  I am inclined to say this fix itself works.
Main problem is Plasma with some DM, but that may not be dependant on this bug?

Ah, i forgot to say i only created users using installer, then userdrake

BTW, thank you for your work.

I see now this Bug 18930 and 17504 are completely parallell now, so i close this as duplicate; lets keep feedbackning there only.

*** This bug has been marked as a duplicate of bug 17504 ***

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