Re: [hylafax-users] PAM Authentication

["Kimble Young" <kimble@xxxxxxxxxxxxxxx>]

Ok I've worked out what happened.

pam_unix.so doesn't work as an unprivileged user such as UUCP so that is the
cause of the local system authentication problems.

pam_mysql.so is buggy and very particular about what you put as its command
options. I had debug which is meant to be implemented in all PAM modules but
not pam_mysql apparently. Removing it made everything work.

I'm sorry for taking up your time Michael, you have been very useful and im
very thankful for your assistance. Thank you also for everyone who thought
carefully about my problem.

To sum things up - Hylafax has a perfectly working PAM implementation just
watch out for  the actual PAM modules.

-----Original Message-----
From: hylafax-users-bounce@xxxxxxxxxxx
[mailto:hylafax-users-bounce@xxxxxxxxxxx]On Behalf Of Kimble Young
Sent: Monday, June 28, 2004 12:13 PM
To: Michael J. Pedersen; hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] PAM Authentication


Update:

I have tried the same setup on an older Redhat 7.3 box with PAM 0.75 and
patched Hylafax 4.1.8.

Exactly the same problem:

Login failed from host [192.168.0.244], fred

I just had a thought.

Doesn't hfaxd change user to uucp on startup?  Wouldn't it have trouble
using pam_unix.so as the UUCP user unless I gave that user access to the
shadow files?

The example PAM application I found - I didn't modify the hylafax code to
match it. I merely compiled the example app and ran it to make sure my PAM
was working as expected.

It works fine as root but when i try it as a non privileged user it fails.



-----Original Message-----
From: hylafax-users-bounce@xxxxxxxxxxx
[mailto:hylafax-users-bounce@xxxxxxxxxxx]On Behalf Of Michael J.
Pedersen
Sent: Sunday, June 27, 2004 10:23 AM
To: hylafax-users@xxxxxxxxxxx
Subject: Re: [hylafax-users] PAM Authentication


On Sat, Jun 26, 2004 at 11:02:54AM +1000, Kimble Young wrote:
> Suggestion 1 didn't work. I've also tried using pam_pwdb same results.  I
> have also tried pam_mysql which causes the hfaxd child processes to
segfault
> repeatedly on authentication attempts.

Now that is truly disturbing. Nothing which is done by pam should cause
the segfault. Any chance you can get a core dump and email it to me? I'd
like to investigate this further.

> 1) Linux kernel 2.4.22-1.2188 on Fedora Core 1

That should be just fine. My machine where it is being used is running
debian, kernel 2.4.18. However, I've installed it on other machines and
kernels with no problems.

> 2) Have been running Hylafax successfully for a few months now with
> hosts.hfaxd authentication based on user/pass. Currently it contains:
>
> 127.0.0.1

Again, that shouldn't be a problem for it. pam isn't looking at that
file. The only reason I checked is because it could, possibly create
conflicts if a user were to be in both places.

> 3) rpm -qa | grep pam
>
> pam-0.77-15
> pam-devel-0.77-15
> pam_smb-1.1.7-2
> pam_krb5-2.0.5-1

Hmmm... I've been using versions 0.72 and 0.76 it turns out, and have
zero issues. I'll ask if you can try 0.76, and see if that works? If
not, it's not a big deal, but it would help to narrow things down still
further.

> 4,5,6) Users exist, can login on console and SSH and I have the correct
> password.

Good. I know, those were probably annoyingly stupid questions, but they
still had to be checked.

> More information:
> I am successfully using pam with pam_mysql to authenticate imap users on
the
> same machine. Eventually I'd like to be using pam_mysql but I am starting
> simple as it's obviously not working.

Good. That eliminates one more possibility for failure. I'm glad to know
you've been using pam for more than this already, it makes life easier.

> http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam_appl-8.html
> Which works just fine for me when I compile it.

Ah, now I'll ask what you mean by the statement that it works fine? Have
you modified the hylafax code to fix it? Or is it just testing the
reference code.

> I don't claim to be a C or C++ expert. In fact it's years since I've
written
> anything in it.  There was one discrepency between the struct in the
> reference application and the code in Hylafax.
>
> example application:
>
> static struct pam_conv conv = {
>     misc_conv,
>     NULL
> };
>
> Hylafax
>         struct pam_conv conv = {
>                 pamconv,
>                 (void*)pass
>         };
>
> The difference looks fairly harmless to me but can anyone with more
> experience see any problems occurring?

Actually, that's necessary to minimize the damage to HylaFAX and still
have it support pam. the '(void*)pass' portion is a segment of client
supplied data, and is quite thoroughly legal to use in this way
according to the pam docs. I very much doubt that this is the issue.

I wish I had more to offer right now, but time grows short for me. Let
me know what you can, and I'll see what I can do.

--
Michael J. Pedersen
My IM IDs: Jabber/pedersen@xxxxxxxxxxxxxx, ICQ/103345809, AIM/pedermj022171
           Yahoo/pedermj2002, MSN/pedermj022171@xxxxxxxxxxx
My GnuPG KeyID: 6CB0A96C       My Public Key Available At: www.keyserver.net
My GnuPG Key Fingerprint: E8F0 920F EB2F 7FDE DF4E  23CC 2CEB 8E6F 6CB0 A96C


____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*



____________________ HylaFAX(tm) Users Mailing List _______________________
  To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
 On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
  *To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*