saslauthd SASL_IPREMOTEPORT -> PAM_RHOST

[Amir 'CG' Caspi]

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
>


-- 
					--- Amir
					3Phase Internet Solutions
					http://www.3phase.com