Page MenuHomeFreeBSD

Put OPIE to rest.
ClosedPublic

Authored by des on Sep 15 2022, 1:41 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 22, 9:16 AM
Unknown Object (File)
Mar 11 2024, 7:41 PM
Unknown Object (File)
Mar 11 2024, 7:41 PM
Unknown Object (File)
Mar 11 2024, 7:41 PM
Unknown Object (File)
Mar 11 2024, 7:41 PM
Unknown Object (File)
Mar 11 2024, 7:40 PM
Unknown Object (File)
Mar 11 2024, 7:40 PM
Unknown Object (File)
Mar 11 2024, 7:21 PM

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 47673
Build 44560: arc lint + arc unit

Event Timeline

des requested review of this revision.Sep 15 2022, 1:41 PM

Can we start by adding deprecation notices to opie.4 and the opie-related section 1 commands and MFC that

what will happen if pam.d/ files still reference pam_opie.so or pam_opieaccess.so - i.e., if the user fails to update /etc somehow?

Can we start by adding deprecation notices to opie.4 and the opie-related section 1 commands and MFC that

Do we have a template for deprecation notices?

what will happen if pam.d/ files still reference pam_opie.so or pam_opieaccess.so - i.e., if the user fails to update /etc somehow?

If they run make delete-old-libs without first updating their PAM policies, they will lock themselves out of everything except the single-user shell.

In D36592#830713, @des wrote:

Do we have a template for deprecation notices?

I don't think we have this documented, but I found an example of one I did in b218441ac074d9cb9417e284980bf87f79a89585

We also had some cases where tools printed the deprecation notice upon invocation, I'll see if I can find an example of one of those

Regenerate after deprecation notices.

I agree with doing this but I think we need to be very careful so that, as much as possible, users (even those who don't consistently read warnings, release notes, etc.) don't get tripped up by the PAM modules disappearing while they still have entries in /etc/pam.d/*.

What do you think about starting by removing them from lib/libpam/pam.d/? We could have freebsd-update emit a warning/error if we are going to remove the modules if they are still referenced - I can take a look at that, if you agree it's a decent idea.

I agree with doing this but I think we need to be very careful so that, as much as possible, users (even those who don't consistently read warnings, release notes, etc.) don't get tripped up by the PAM modules disappearing while they still have entries in /etc/pam.d/*.

What do you think about starting by removing them from lib/libpam/pam.d/? We could have freebsd-update emit a warning/error if we are going to remove the modules if they are still referenced - I can take a look at that, if you agree it's a decent idea.

This won't happen unless they run make delete-old-libs but not etcupdate.

rebase, remove opielocks, fix whitespace nit

This revision is now accepted and ready to land.Oct 2 2022, 1:49 AM