Support for long running kcheckpass supporting multiple authentications

Authored by graesslin on Mar 10 2017, 6:07 AM.



So far kcheckpass allowed to try to verify one password. This required
kscreenlocker_greet to exec for every new entered password. Due to that
we cannot enable seccomp in kscreenlocker_greet.

This change prepares for supporting seccomp by making it possible to
have a long living kcheckpass with multiple authentications. For that
the interaction is changed:

  • kcheckpass gets started without going into Authenticate directly
  • kcheckpass uses a signalfd for waiting on sigusr1 and sigusr2
  • kcheckpass goes into a loop for authentication
    • signals parent process through socket that it is ready for auth
    • waits for signal
    • on sigusr1 starts to authenticate
    • on sigusr2 goes out of loop
    • after authenticate goes into next loop run to continue

For the authenticator in kscreenlocker_greet the main change is to
send the signal to kcheckpass when it wants to authenticate.

In addition the authenticator supports both a delayed and a direct
mode. In the delayed case kcheckpass gets started directly on startup
for the long living process. In the direct mode it starts kcheckpass
when going into authenticate. We need both modes as kcheckpass is not
supposed to use the long living process when it is setuid root.

For the moment kscreenlocker_greet by default still uses the direct
interaction. This will change when seccomp integration is added.

The test application gained a new command line switch to use either
direct or delayed authentication.

Diff Detail

R133 KScreenLocker
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
graesslin created this revision.Mar 10 2017, 6:07 AM
Restricted Application added a project: Plasma. · View Herald TranscriptMar 10 2017, 6:07 AM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
romangg added inline comments.

Can we only use the enum class in Authenticator, instead of duplicating it here?


Shouldn't we test this before we write the result to the socket (and then write an error as result)?

graesslin added inline comments.Mar 26 2017, 7:44 PM

I don't like using enums defined in other classes. But moving it a level up into the namespace would be an option.


No, we need to support the setuid case. It is used by bsds and slackware. So we need to support general authentication. The break here is more a better safe than sorry thingy. Technically it would support the long running also in setuid. But I don't trust the code. So to decrease the attack surface we do an early exit.

graesslin updated this revision to Diff 13188.Apr 7 2017, 1:02 PM

Declare enum globally instead of as a class member. Thus we don't have to have the same enum in two classes

I have problems applying this patch properly:

roman@laptop ..kde/source/kde/workspace/kscreenlocker (git)-[master] % git apply D4806.diff 
roman@laptop ..kde/source/kde/workspace/kscreenlocker (git)-[master] % git apply D4997.diff 
error: authenticator.h: No such file or directory
error: authenticator.cpp: No such file or directory
error: autotests/authenticatortest.cpp: No such file or directory
error: greeterapp.cpp: No such file or directory
error: kcheckpass-enums.h: No such file or directory
error: kcheckpass.c: No such file or directory
error: kcheckpass_test.cpp: No such file or directory
This revision was automatically updated to reflect the committed changes.