FS#61300 - [physlock] Infinite loop with pambase 20190105.1-1
Attached to Project:
Community Packages
Opened by Mateusz Gozdek (invidian) - Monday, 07 January 2019, 16:52 GMT
Last edited by Ivy Foster (escondida) - Tuesday, 08 January 2019, 21:49 GMT
Opened by Mateusz Gozdek (invidian) - Monday, 07 January 2019, 16:52 GMT
Last edited by Ivy Foster (escondida) - Tuesday, 08 January 2019, 21:49 GMT
|
Details
Description:
Recent updates to pambase package (https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pambase&id=3552aba772e8bebbe754a4d01f2729e291dd2070) changed default policy, which physlock relied on. With new version of pambase package, when "physlock -m" is executed, physlock enters infinite loop where only option is reboot (or killing over SSH). The workaround for this is described here: https://github.com/muennich/physlock/issues/47#issuecomment-274445853. I think creating "/etc/pam.d/physlock" could be done by the package. Additional info: * pambase 20190105.1-1, physlock 11-3 Steps to reproduce: - Update pambase to 20190105.1-1 - Execute "physlock -m" |
This task depends upon
Closed by Ivy Foster (escondida)
Tuesday, 08 January 2019, 21:49 GMT
Reason for closing: Fixed
Additional comments about closing: Provided pam configuration for physlock, based on the one upstream is currently considering shipping.
Tuesday, 08 January 2019, 21:49 GMT
Reason for closing: Fixed
Additional comments about closing: Provided pam configuration for physlock, based on the one upstream is currently considering shipping.
I also tested with physlock master build and it is still occurring without /etc/pam.d/physlock file, so I will also report bug upstream, as it clearly is a bug.
I think this one can be now closed.
As to how it affects security, physlock isn't getting any *new* privileges; it's just retaining the ones it previously gained from /etc/pam.d/other, so it's as safe or not-safe as it was before.