Hello,
I maintain Poldi in Debian, as a package maintainer, because it would
be useful in some situation.
In private mail, I was asked about Poldi in the context of this bug (of
libkscreenlocker5):
https://bugs.debian.org/934185
Since it is better to discuss in public, I bring it here.
In the past, similar bug is reported with SDDM. It was reported to
gnupg-devel with a proposed patch for Poldi:
https://lists.gnupg.org/pipermail/gnupg-devel/2018-November/thread.html#34063
But, the proposed patch (which removes conversation upcall from Poldi)
doesn't work well for other valid use case (of lightdm). So, it was not
applied.
In my opinion, it is wrong to change Poldi to work around for this kind
of bug.
This time, I investigated the cause in detail (in my environment).
For mine (I use Debian), and the relevant code is:
The executable kcheckpass:
https://sources.debian.org/src/kscreenlocker/5.14.5-1/kcheckpass/
and
The greeter (for GUI):
https://sources.debian.org/src/kscreenlocker/5.14.5-1/greeter/
The kcheckpass does it correctly (handling "conv"ersation between PAM
module).
IIUC, it is the greeter which is need to be fixed.
The password is only set once at tryUnlock function at first, and the
function which handles conversation between PAM module repeatedly
returns this same password by handleVerify function (forever), without
asking to a user at all. This implementation only works when a PAM
module does no upcall.
Te elaborate...
The greeter only implements PAM support partially which only works well
in a specific situation; It only works when the first pass goes well.
It doesn't work well when PAM module asks the second pass (or more) with
conversation feature.
Here is a figure to explain interaction.
==========================
A user of a PAM module A PAM module
(greeter+kcheckpass) (libpam-poldi)
(1) Simplest case: only with the first pass
-->With a PIN from human user
Ask authenticate -->
<-- PAM_SUCCESS
Good, it works.
(2) General case(s): multiple passes
Ask authenticate -->
again:
<-- Up call by PAM_CONV
for new PIN
with a message of error (PIN too short)
<-- should ask human user again
--> new PIN
it answers back with new PIN -->
go again if a PAM module asks PAM_CONV again
Or, finally it comes with:
<-- PAM_SUCCESS
or
<-- PAM_AUTH_ERR
==========================
The greeter never implements the case of (2) correctly:
https://sources.debian.org/src/kscreenlocker/5.14.5-1/greeter/authenticator.cpp/#L245
Here, it returns back with same string by GSendStr, without asking new
PIN to human.
--
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
I maintain Poldi in Debian, as a package maintainer, because it would
be useful in some situation.
In private mail, I was asked about Poldi in the context of this bug (of
libkscreenlocker5):
https://bugs.debian.org/934185
Since it is better to discuss in public, I bring it here.
In the past, similar bug is reported with SDDM. It was reported to
gnupg-devel with a proposed patch for Poldi:
https://lists.gnupg.org/pipermail/gnupg-devel/2018-November/thread.html#34063
But, the proposed patch (which removes conversation upcall from Poldi)
doesn't work well for other valid use case (of lightdm). So, it was not
applied.
In my opinion, it is wrong to change Poldi to work around for this kind
of bug.
This time, I investigated the cause in detail (in my environment).
For mine (I use Debian), and the relevant code is:
The executable kcheckpass:
https://sources.debian.org/src/kscreenlocker/5.14.5-1/kcheckpass/
and
The greeter (for GUI):
https://sources.debian.org/src/kscreenlocker/5.14.5-1/greeter/
The kcheckpass does it correctly (handling "conv"ersation between PAM
module).
IIUC, it is the greeter which is need to be fixed.
The password is only set once at tryUnlock function at first, and the
function which handles conversation between PAM module repeatedly
returns this same password by handleVerify function (forever), without
asking to a user at all. This implementation only works when a PAM
module does no upcall.
Te elaborate...
The greeter only implements PAM support partially which only works well
in a specific situation; It only works when the first pass goes well.
It doesn't work well when PAM module asks the second pass (or more) with
conversation feature.
Here is a figure to explain interaction.
==========================
A user of a PAM module A PAM module
(greeter+kcheckpass) (libpam-poldi)
(1) Simplest case: only with the first pass
-->With a PIN from human user
Ask authenticate -->
<-- PAM_SUCCESS
Good, it works.
(2) General case(s): multiple passes
Ask authenticate -->
again:
<-- Up call by PAM_CONV
for new PIN
with a message of error (PIN too short)
<-- should ask human user again
--> new PIN
it answers back with new PIN -->
go again if a PAM module asks PAM_CONV again
Or, finally it comes with:
<-- PAM_SUCCESS
or
<-- PAM_AUTH_ERR
==========================
The greeter never implements the case of (2) correctly:
https://sources.debian.org/src/kscreenlocker/5.14.5-1/greeter/authenticator.cpp/#L245
Here, it returns back with same string by GSendStr, without asking new
PIN to human.
--
_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
