Poldi (no-)change

[NIIBE Yutaka]

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.
--