kcheckpass auth methods

Martin Gräßlin mgraesslin at kde.org
Sun Feb 26 08:20:48 GMT 2017


Am 2017-02-25 21:52, schrieb Adriaan de Groot:
> Hi Martin, thanks for bringing this up.
> 
> On Friday 24 February 2017 15:59:22 Martin Gräßlin wrote:
>> I'm currently cleaning up the kcheckpass code (kscreenlocker 
>> repository)
>> and are wondering what is still needed.
>> 
>> We currently have code for the following auth backends:
>> * pam
>> * OSF/1 C2 security extension
> 
> I can say fairly certainly that that's OSF, or Tru64 -- DEC Alpha UNIX 
> stuff,
> from way way back. (Supporting my memory is, for instance,
> https://lists.samba.org/archive/samba-ntdom/1999-September.txt ) I 
> expect it's
> fair to say that Tru64 is no longer a supported platform for KDE.

oh nice, thanks for sharing. I guess I can put that on the list for 
removal.
So far I'm planning to remove:
* OSF
* AIX
* /etc/passwd

> 
>> I would like to know if any distribution (including BSDs) is using
>> something different than PAM and if yes which one. For the linux
>> distributions I would like to know whether we can enforce PAM at 
>> compile
>> time in case we detect compilation on linux (I got too many bug 
>> reports
>> about not being able to unlock due to the optional dependency, hello
>> Gentoo users knowing how to set proper flags :-P ).
> 
> FreeBSD uses PAM. It also setuid's kcheckpass. I'm taking a look at 
> what is
> actually needed there now (results later).

That's a difference to our cmake as setuid is only set when PAM is not 
used.
Would be interesting to see why you need it. In case that you still need 
it, please tell as I'm planning changes which can only go into the 
non-setuid variant and then I would not be able to use the PAM-found as 
condition.

> Like I said above, we carry some patches to suggest something else and 
> provide
> a helper script for consolekit.

If you want to upstream: we are happy to support more than loginctl 
here.

Cheers
Martin



More information about the Distributions mailing list