Re: cant login after make installworld: pam_opie.so.6 not found
Hi Dag-Erling no problem at all , i just wanted to pass thru the login thats it. its working fine with this new pam_login_access.so / pam_unix.so (not sure which one we are using now) thanks --tzk On Fri, 6 Jan 2023, Dag-Erling Smørgrav wrote: Ivan Quitschal writes: I had to "install" the new temporary /etc/pam.d files with mergemaster. I think the problematic file was the "system" config file. Now its all fine If you wish to continue to use OPIE (which I don't recommend), there is now a port (security/opie). You will have to manually add back the pam_opie and pam_opieaccess lines in the relevant PAM policies. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: cant login after make installworld: pam_opie.so.6 not found
Ivan Quitschal writes: > I had to "install" the new temporary /etc/pam.d files with mergemaster. I > think the problematic file was > the "system" config file. Now its all fine If you wish to continue to use OPIE (which I don't recommend), there is now a port (security/opie). You will have to manually add back the pam_opie and pam_opieaccess lines in the relevant PAM policies. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: cant login after make installworld: pam_opie.so.6 not found
On 1/6/23, Xin Li wrote: > Security team has discussed this a decade ago. See > https://www.miknet.net/security/skey-dungeon-attack/ > for technical details. That would mean that FreeBSD knowingly left users exploitable without doing even the "easy fix" in that article to the opie code for over a decade. And further left opie vulnerable and present since the commit in all RELENG, STABLE, and handbook. And did not issue a SA on it since the commit, nor ever since the article. If attempting to claim security as reason to delete, then FreeBSD might appear to be faulty of this. Which would present good opportunity to consider any potential improvements to that process too. > And this could have been avoided if user have followed source upgrade Lockout avoided... yes maybe if users wanted to quit their opie forever at that moment, but if not, then opie code module hasn't yet been moved to ports for anyone to use and or update as they wish. The nature of port security in every unix OS is 3rd-party and un-dedicated, so that wouldn't be reason not to port such things either. Onward :)
