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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ivy Foster (escondida)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

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.
Comment by Ivy Foster (escondida) - Monday, 07 January 2019, 23:54 GMT
invidian, I've just uploaded physlock 11-4, with a pam module per upstream's bug report. Can you confirm that this fixes the issue with pambase 20190105?
Comment by Mateusz Gozdek (invidian) - Tuesday, 08 January 2019, 08:24 GMT
Hi, thanks for quick care about it! I tested it on vagrant box with both pambase 20190105.1-1 and 20171006-1 and everything seems to work. My only concern is how this file affects security, but I guess it should be fine.

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.
Comment by Ivy Foster (escondida) - Tuesday, 08 January 2019, 21:48 GMT
Thanks for double-checking that, invidian!

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.

Loading...