kcheckpass auth methods

[Adriaan de Groot]

Hi Martin,

It took a little while to sort out, but it looks like PAM on Linux and PAM on 
FreeBSD take very different approaches when it comes to the PAM module pam_unix 
(i.e. the local /etc/passwd or /etc/shadow checking).

Here's a note from the FreeBSD manpage of pam_unix:

                     NOTE: If pam_unix is invoked by a process that does not
                     have the privileges required to access the password data-
                     base (in most cases, this means root privileges), the
                     nullok option may cause pam_unix to allow any user to log
                     in with any password.

While the Linux manpage (I checked on OpenSUSE 42) says:

       A helper binary, unix_chkpwd(8), is provided to check the user's
       password when it is stored in a read protected database. This binary is
       very simple and will only check the password of the user invoking it.
       It is called transparently on behalf of the user by the authenticating
       component of this module. In this way it is possible for applications
       like xlock(1) to work without being setuid-root.

In other words, on Linux the setuid bit is just pushed somewhere down the 
stack.

On Sunday 26 February 2017 09:20:48 Martin Gräßlin wrote:
> > 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.

Well, so we need PAM *and* setuid -- at least on the common setup where 
pam_unix is used. What kind of changes are these? Why are they non-setuid 
only? (I suppose I could try compiling kcheckpass master to see what's up, 
regardless).

[ade]