saslauthd SASL_IPREMOTEPORT -> PAM_RHOST

[Lorenzo M. Catucci]

Amir,
    sorry for not getting back sooner; what you are seeing is the effect
of a deliberate choice,
as you can see from the following log lines, stemming out of pam login
handling on my test system:
in the first case, the pam module does set the user PAM ITEM for an
existing user; in the second case,
the user is unknown and MUST not be set.

I don't have the PAM history handy, but what could have been printed is
the logname, which is
deliberately omitted.

As things stand, I prefer to restrain from setting a value for the RUSER
item*, following the choices made
by well audited applications like openssh and login.

Thank you very much, yours

            lorenzo

May 23 20:00:25 test saslauthd[28565]: pam_unix(pop:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=::1 
user=existing
May 23 20:00:26 test saslauthd[28565]: DEBUG: auth_pam: pam_authenticate
failed: Authentication failure
May 23 20:00:26 test saslauthd[28565]: do_auth         : auth failure:
[user=existing] [service=pop] [realm=] [remote=::1;49963] [mech=pam]
[reason=PAM auth error]
May 23 20:01:22 test saslauthd[28567]: pam_unix(pop:auth): check pass;
user unknown
May 23 20:01:22 test saslauthd[28567]: pam_unix(pop:auth):
authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=::1
May 23 20:01:24 test saslauthd[28567]: DEBUG: auth_pam: pam_authenticate
failed: Authentication failure
May 23 20:01:24 test saslauthd[28567]: do_auth         : auth failure:
[user=ba] [service=pop] [realm=] [remote=::1;49964] [mech=pam]
[reason=PAM auth error]

* As you can see at
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_ADG.html ,
  PAM_USER should get set by the PAM stack after authentication; I'm
also unsure about the expected
  PAM_RUSER semantics, since both the behavior of su and my reading of
the PAM_RUSER paragraph
  point to a ruser variable being set when the REQUESTING user is well
known.
 
 


On 05/23/2011 07:31 PM, Amir 'CG' Caspi wrote:
> On Mon, 23 May 2011 at 02:59:58 -0700, Amir 'CG' Caspi wrote:
>>     As for the remote user, I can see that saslauthd does receive
>> that info, but it doesn't log it via PAM, as you can see.  I believe
>> this is because the remote user is not being passed into the correct
>> field of the pamh struct, within auth_pam.  It's being passed into
>> the login field, but it should also be passed into the user field, I
>> believe.  I'm not a PAM expert, so I can't be sure, but I think this
>> is the case.
>
> After looking at auth_pam() some more and after reading a bit of PAM
> documentation, I think that in addition to PAM_RHOST, one also needs
> to set PAM_USER.  This is done with pam_set_item, just as for PAM_RHOST.
>
> I *THINK* a simple call such as:
>
> pam_set_item(pamh, PAM_USER, login)
>
> would work to get PAM to recognize the username and log it
> appropriately.  This would be done in the same place as setting
> PAM_RHOST.
>
> Could you try this on your patched copy to see if it works?  If so,
> the patch can be updated to include this line, and I think that would
> fix pretty much everything. =)
>
> Thanks!
>                         --- Amir
>
>
>>     The default configuration for most systems is not to log
>> debug-level info, so all we see is the * line, which has no user
>> info.  I think if the username is passed into the correct field of
>> the pamh struct, this should be fixed... I'm just not sure which is
>> the correct field.
>>
>> Thanks. =)
>>                         --- Amir
>>
>> At 10:15 AM +0200 05/23/2011, Lorenzo M. Catucci wrote:
>>> Amir,
>>>     I just checked the 2.1.23 patch applies with just some line shift
>>> to 2.1.22. I have no handy way to test it and I have no experience with
>>> SRMPs, specs and the like, since my systems are debian based. I'd be
>>> VERY grateful if you could try yourself to create a patched RPM for
>>> a test
>>> system of yours!
>>>
>>> As for the "pass the requested login name", saslauthd does know the
>>> login
>>> name, as it must be passed to the auth handlers; if you set the syslog
>>> level for the authpriv syslog destination to debug, you'll be able
>>> to see
>>> lines like the following ones:
>>>
>>> May 23 09:53:36 test saslauthd[28570]: pam_unix(svc:auth): check
>>> pass; user unknown
>>> May 23 09:53:36 test saslauthd[28570]: pam_unix(svc:auth):
>>> authentication failure; logname= uid=0 euid=0 tty= ruser=
>>> rhost=127.0.0.1 **
>>> May 23 09:53:38 test saslauthd[28570]: DEBUG: auth_pam:
>>> pam_authenticate failed: Authentication failure
>>> May 23 09:53:38 test saslauthd[28570]: do_auth         : auth
>>> failure: [user=cg] [service=svc] [realm=] [remote=127.0.0.1;42002]
>>> [mech=pam] [reason=PAM auth error] **
>>>
>>> Since that is the default configuration on my systems, I didn't get
>>> the problematic * line, since all you need is shown in **.
>>>
>>> I don't make any promise, but I'll try to understand this glitch.
>>>
>>> Thank you very much, yours
>>>
>>>     lorenzo
>>
>
>