Bugzilla – Bug 1155695
Password encryption method depends on whether Expert Options - Password Encryption was called
Last modified: 2019-11-21 22:46:27 UTC
There is quite weird interaction between YaST Users and Security modules. During creation of user YaST is using current encryption method from Security module. I.e. in src/modules/Users.pm:CryptPassword(): my $method = lc ($encryption_method); Where $encryption_method is defined as my %security = %{Security->Export ()}; $encryption_method = $security{"PASSWD_ENCRYPTION"} || $encryption_method; Unfortunately in Security PASSWD_ENCRYPTION member is defined as sha512 if Read was not called and *des*!!! is Read was called and /etc/logins.def is not present or ENCRYPT_METHOD is not defined there: # All security settings @Settings = { ... "PASSWD_ENCRYPTION" => "sha512", but later def read_encryption_method method = SCR.Read(path(".etc.login_defs.ENCRYPT_METHOD")).to_s.downcase method = "des" if !@encryption_methods.include?(method) @Settings["PASSWD_ENCRYPTION"] = method end def read_pam_settings read_encryption_method ... def Read @Settings = {} ... read_pam_settings The effect is following: - if I call YaST Users module, create user and save changes, user gets sha512 password because this is built-in default and Security.Read() was not invoked. - if I call YaST Users module, display Expert Options - Password Encryption (only display, without changing anything!) Security.Read is called and if ENCRYPT_METHOD is not defined there, internal default is changed to "des" from "sha512". Displaying current values without changing them must not change behavior.
I'll confirm this. And thanks for reporting it. I first noticed this in the install that I reported (for other problems) in bug 1155687 (if you need Yast logs, they are in that report). I then did a fresh install, this time using the DVD installer. And the same problem. The initially configured user has a password with DES encryption, while the root user (same password) is using sha512 for the encryption. I then tested the "passwd" command to create a password for a new user, and that used sha512. According to the man pages for "passwd", the encryption method default is set in "/etc/login.def". But that file does not exist. It seems to have been moved to "/usr/etc/login.def" (which does exist). So the man page is out of date. But I wonder whether this odd behavior during install is somehow related to that move of "login.def" from "/etc" to "/usr/etc".
(In reply to Neil Rickert from comment #1) > > I then did a fresh install, this time using the DVD installer. And the same > problem. The initially configured user has a password with DES encryption, > while the root user (same password) is using sha512 for the encryption. > Thanks, I intended to test it. This confirms my observation - at the installer summary it likely calls Security.Read which resets password encryption to "des". > I then tested the "passwd" command to create a password for a new user, and > that used sha512. > Correct, passwd reads default from /usr/etc/login.def which defines sha512 as default encryption. > According to the man pages for "passwd", the encryption method default is > set in "/etc/login.def". But that file does not exist. It seems to have > been moved to "/usr/etc/login.def" (which does exist). So the man page is > out of date. But I wonder whether this odd behavior during install is > somehow related to that move of "login.def" from "/etc" to "/usr/etc". This is part of ongoing unification - packages are expected to install default values into /usr/etc (search for discussion on factory). What is *not* clear - how defaults are supposed to be customized in each case. I.e. - will /etc/login.defs supersede /usr/etc/login.def? Will they be merged with individual settings in /etc/login.def overriding /usr/etc/login.def? ... h-m-m ... shadow changelog mentions libeconf. Reading summary (https://github.com/openSUSE/libeconf) suggest that /etc/login.def supersedes /usr/etc/login.def. Anyway, it also means that YaST Security module must be suitably adapted - it must be prepared to read current configuration from /usr/etc/login.def *and* also from /etc/login.def.d (see libeconf readme). And probably instead of writing /etc/login.def write suitable drop-in under /etc/login.def.d. And this is just tip of iceberg ...
(In reply to Andrei Borzenkov from comment #0) > > - if I call YaST Users module, create user and save changes, user gets > sha512 password because this is built-in default and Security.Read() was not > invoked. > > - if I call YaST Users module, display Expert Options - Password Encryption > (only display, without changing anything!) Security.Read is called and if > ENCRYPT_METHOD is not defined there, internal default is changed to "des" > from "sha512". > Sorry, I cannot reproduce it now. YaST is always using DES. (In reply to Andrei Borzenkov from comment #2) > > Anyway, it also means that YaST Security module must be suitably adapted - > it must be prepared to read current configuration from /usr/etc/login.def > *and* also from /etc/login.def.d (see libeconf readme). And probably instead > of writing /etc/login.def write suitable drop-in under /etc/login.def.d. > That remains. I opened separate bug report for it. https://bugzilla.opensuse.org/show_bug.cgi?id=1155735
>Sorry, I cannot reproduce it now. YaST is always using DES. I'll try another test install when the next snapshot comes out.
I did a test install with the 20191104 KDE live media. I repeated twice. The first time just a direct install (which could not boot into the GUI). The second time, I stopped "nscd" before starting the install. And this gave a better install. In both case, the root password encryption used SHA256, while the defined user encryption use DES. Both had the same password. So that inconsistency is still there.
Andrei, as you mentioned you already reported https://bugzilla.opensuse.org/show_bug.cgi?id=1155735 and this bug seems related to it. There is already a PBI in our Incoming Board for handling it correctly so, I guess we could close this one as duplicate of that one. Do you agree?
*** Bug 1156552 has been marked as a duplicate of this bug. ***
(In reply to Knut Alejandro Anderssen González from comment #6) > Andrei, as you mentioned you already reported > https://bugzilla.opensuse.org/show_bug.cgi?id=1155735 and this bug seems > related to it. > > There is already a PBI in our Incoming Board for handling it correctly so, I > guess we could close this one as duplicate of that one. > > Do you agree? It is not really a duplicate but as I mentioned I cannot reproduce the problem, so may be it was user error on my part initially. Also currently it is impossible to actually test it as YaST will always use DES anyway. I'm fine with simply closing it as "cannot reproduce".
Thanks for the input, Andrei. There is no the suggested "cannot reproduce" option, so closing it as "WORKSFORME".