Re: understanding 'likeauth'
Gagan Sidhu <[email protected]> Tue, 22 May 2018 19:06:44 -0600
| Newsgroups | gmane.linux.pam |
|---|---|
| Message-ID | <[email protected]> |
--===============6598109320954472792==
Content-type: multipart/alternative;
boundary="Apple-Mail=_E4832AE8-3125-4406-8822-E34DEA4B51CB"
--Apple-Mail=_E4832AE8-3125-4406-8822-E34DEA4B51CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
my current issue certainly feels like a continuation of an =
almost-fifteen year old post, so first let us distribute thy credit=E2=80=A6=
>=20
> From: Rafa Forcada <rforcada join-es com>
>=20
> To: pam-list redhat com
>=20
> Subject: Re: understanding 'likeauth'
>=20
> Date: Mon, 12 Jan 2004 17:08:52 +0100 (CET)
>> On Sun, 11 Jan 2004, Brian Jones wrote:
>>=20
>> > Hi all,
>> >
>> > I've been trying to find a good explanation for exactly what the
>> > 'likeauth' parameter to the pam_unix module actually does, when
>> > (precisely) it should be used, etc.
>> >
>> > I've found a couple of places through google searches where this is
>> > discussed, but I'm still not sure if I get it. My understanding is =
that
>> > if you have pam_unix listed as 'sufficient' and another module =
under it
>> > listed as 'required', then 'likeauth' needs to be used to ensure =
that
>> > the value returned by the 'sectcred()' function of the *second* =
module
>> > is the one returned to the application (assuming, of course, that =
the
>> > second module succeeds, of course).
>> >
>> > This is confusing, because I though that if any part of the module
>> > failed, the module returns a failed status, and things move to the =
next
>> > module. This explanation seems to imply that multiple values are
>> > returned from pam_unix, one for 'auth()', and one for 'setcred()', =
and
>> > the failure of one doesn't mean the module fails? Is the module =
called
>> > twice or something? What's the order of operations in the (quite =
common)
>> > scenario of having:
>> >
>> > auth sufficient /lib/security/$ISA/pam_unix.so likeauth =
nullok
>> > auth required /lib/security/$ISA/pam_deny.so
>> >
>> > Why do I need 'likeauth' here? What happens if I remove it?
>> >
>> > Can anyone shed s'more light or give a better example of the
>> > consequences of using or not using likeauth?
>> >
>>=20
>=20
> Hi there!
>=20
> If you check out the source code of pam_unix (pam_unix_auth.c), you =
will
> find the answer.
>=20
> When pam_unix is required for auth, pam calls 2 functions into it:
> pam_sm_authenticate and pam_sm_setcred.
>=20
> In my opinion, pam calls pam_sm_authenticate and pam_sm_setcred one =
after
> another.
>=20
> If you provide the 'likeauth' parameter, pam_sm_setcred returns the =
same value
> as pam_sm_authenticate (this last one stores it), I think that is the =
reason
> why the parameter is called 'likeauth': return the same value as =
pam_sm_authenticate.
>=20
> I'm not sure about what is the real value returned to the pam library.
> Does that mean that if pam_sm_authenticate fails and no 'likeauth' has
> been specified, the returned value is 'success' because pam_sm_setcred
> returns success?
>=20
> --
> __
> _ __ __ _ / _| __ _
> | '__/ _` | |_ / _` |
> | | | (_| | _| (_| |
> |_| __ _|_| __ _|
>=20
> Rafa Forcada Mart=C3=ADnez
> mailto:rforcada <mailto:rforcada> join-es com
>=20
> JOvenes INform=C3=A1ticos
> http://www.join-es.com <http://www.join-es.com/>
>=20
in my current setup, i=E2=80=99ve managed to make this legacy httpd =
application authenticate against pam in =E2=80=98normal=E2=80=99 =
situations.
that is, when a user accesses the kernel=E2=80=99s router interface via =
192.168.1.1, they must give their password which is then verified =
through PAM.
i used this code here: https://stackoverflow.com/a/5970078/1932859 =
<https://stackoverflow.com/a/5970078/1932859> to parse the user input in =
the http header and pass it off to pam.
amazingly this works quite well. and even when the password is changed =
via =E2=80=98passwd=E2=80=99 in shell, the interface will pick it up =
quite fast and consequently re-prompt for new credentials.
there is one strange situation, however, when it comes to =
=E2=80=98demanding=E2=80=99 pages.=20
on what i define as a =E2=80=98demanding page=E2=80=99, there are =
approximately 20+ interfaces, each with their own dynamically-generated =
svg graphic depicting the current throughput of each interface.=20
presumably all of this information must be transmitted through httpd, =
but i am not sure.
-what i am sure of, however, is that only on this =
=E2=80=98demanding=E2=80=99 page do i get the following error thrown by =
pam:
> May 22 18:31:32 DD-WRT httpd[536]: pam_unix(httpd:auth): auth could =
not identify password for [root]
> May 22 18:31:32 DD-WRT httpd[536]: pam_unix(httpd:auth): auth could =
not identify password for [root]
followed by this segfault in the program:
> May 22 18:31:32 DD-WRT : Caught SIGSEGV (11) sent by kernel in ???=20
> May 22 18:31:32 DD-WRT : Thread 2373: httpd=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Context:=20
> May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 =
V1:00000001 A0:6677656e A1:00000001=20
> May 22 18:31:32 DD-WRT : A2:00000010 A3:74600471 T0:00000001 =
T1:00000fa6 T2:00000000 T3:006e7275=20
> May 22 18:31:32 DD-WRT : T4:76dbae28 T5:77c28020 T6:004400b0 =
T7:746005b8 S0:746004b0 S1:77adda30=20
> May 22 18:31:32 DD-WRT : S2:746005b0 S3:74600470 S4:76dbb920 =
S5:00000000 S6:00409804 S7:76dbb920=20
> May 22 18:31:32 DD-WRT : T8:00000000 T9:77ad90e8 K0:7460049b =
K1:00000000 GP:77bf7e20 SP:76dbaee8=20
> May 22 18:31:32 DD-WRT : FP:76dbaf40 RA:77bb4484=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Backtrace:=20
> May 22 18:31:32 DD-WRT : # [0x77bb442c]: ra offset 44=20
> May 22 18:31:32 DD-WRT : # [0x77bb4418]: stack size 48=20
> May 22 18:31:32 DD-WRT : # [0x77bb45e8]: ra offset 36=20
> May 22 18:31:32 DD-WRT : # [0x77bb45d0]: stack size 40=20
> May 22 18:31:32 DD-WRT : # [0x77bfbb54]: ra offset 172=20
> May 22 18:31:32 DD-WRT : # [0x77bfbb28]: stack size 176=20
> May 22 18:31:32 DD-WRT : # [0x77b5768c]: stack size 32=20
> May 22 18:31:32 DD-WRT : # [0x77b57678]: stack size 32=20
> May 22 18:31:32 DD-WRT : # [0x77b5761c]: stack size 32=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](+0x00160474)[0x77bb4474]=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](__libc_thread_freeres+0x00000058)[0x77bb461c]=20=
> May 22 18:31:32 DD-WRT : =
/lib/libpthread.so.0[0x77bf5000](+0x00006c84)[0x77bfbc84]=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](+0x001036ac)[0x77b576ac]=20
> May 22 18:31:32 DD-WRT : ???(+0)[0x77f9b030]=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Code:=20
> May 22 18:31:32 DD-WRT : 77bb4434: afb10020 afb0001c 1260001c =
26700040 00602025 8f8394f0 ac400000 00641821=20
> May 22 18:31:32 DD-WRT : 77bb4454: 24020001 8f9187ec a0620000 =
26720140 8e040000 00000000 10800009 00000000=20
> May 22 18:31:32 DD-WRT : 77bb4474: >8c820000 0220c825 0320f809 =
ae020000 8e040000 00000000 1480fff9 00000000=20
> May 22 18:31:32 DD-WRT : 77bb4494: 26100004 1650fff2 0220c825 =
0320f809 02602025 8fbc0010 00000000 8f8294e8=20
> May 22 18:31:32 DD-WRT : Caught SIGABRT (6) sent by tkill=20
> May 22 18:31:32 DD-WRT : Thread 2374: httpd=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Context:=20
> May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 =
V1:74ffec00 A0:00000003 A1:74ffec00=20
> May 22 18:31:32 DD-WRT : A2:00000000 A3:00000000 T0:00000000 =
T1:00000401 T2:00000001 T3:77fa7000=20
> May 22 18:31:32 DD-WRT : T4:00002000 T5:fffffffc T6:00100000 =
T7:00001072 S0:00000000 S1:74ffec00=20
> May 22 18:31:32 DD-WRT : S2:77bf4000 S3:00000010 S4:77ae4c70 =
S5:77f9a000 S6:00000002 S7:00000002=20
> May 22 18:31:32 DD-WRT : T8:77abf088 T9:77a85fb0 K0:00000010 =
K1:00000000 GP:77bf7e20 SP:74ffeb78=20
> May 22 18:31:32 DD-WRT : FP:74ffee10 RA:77a87754=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Backtrace:=20
> May 22 18:31:32 DD-WRT : # [0x77a85fc0]: stack size 272=20
> May 22 18:31:32 DD-WRT : # [0x77a875e4]: ra offset 316=20
> May 22 18:31:32 DD-WRT : # [0x77a875dc]: stack size 320=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](gsignal+0x000000d0)[0x77a86080]=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](abort+0x00000184)[0x77a87754]=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](__libc_fatal+0x00000000)[0x77ace564]=20
> May 22 18:31:32 DD-WRT : =
/usr/lib/libutils.so[0x77c7f000](+0x00014b74)[0x77c93b74]=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Code:=20
> May 22 18:31:32 DD-WRT : 77a86040: 0000000c 00402025 2402107e =
0000000c 00402825 02003025 240210aa 0000000c=20
> May 22 18:31:32 DD-WRT : 77a86060: 14e0000c 00408025 24040003 =
02202825 00003025 24070010 24021063 0000000c=20
> May 22 18:31:32 DD-WRT : 77a86080: >02001025 8fb1010c 8fb00108 =
03e00008 27bd0110 8f8294d8 7c03e83b 00431021=20
> May 22 18:31:32 DD-WRT : 77a860a0: ac500000 1000fff0 2410ffff =
00000000 3c1c0017 279c1d70 0399e021 04800005=20
> May 22 18:31:32 DD-WRT : Caught SIGABRT (6) sent by tkill=20
> May 22 18:31:32 DD-WRT : Thread 2370: httpd=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Context:=20
> May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 =
V1:7789fc00 A0:00000003 A1:7789fc00=20
> May 22 18:31:32 DD-WRT : A2:00000000 A3:00000000 T0:00000000 =
T1:00000401 T2:77f99000 T3:77fa7000=20
> May 22 18:31:32 DD-WRT : T4:00002000 T5:fffffffc T6:00100000 =
T7:00001072 S0:00000000 S1:7789fc00=20
> May 22 18:31:32 DD-WRT : S2:77bf4000 S3:00000010 S4:77ae4c70 =
S5:77f99000 S6:00000002 S7:00000002=20
> May 22 18:31:32 DD-WRT : T8:77abf088 T9:77a85fb0 K0:00000010 =
K1:00000000 GP:77bf7e20 SP:7789fb78=20
> May 22 18:31:32 DD-WRT : FP:7789fe10 RA:77a87754=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Backtrace:=20
> May 22 18:31:32 DD-WRT : # [0x77a85fc0]: stack size 272=20
> May 22 18:31:32 DD-WRT : # [0x77a875e4]: ra offset 316=20
> May 22 18:31:32 DD-WRT : # [0x77a875dc]: stack size 320=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](gsignal+0x000000d0)[0x77a86080]=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](abort+0x00000184)[0x77a87754]=20
> May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](__libc_fatal+0x00000000)[0x77ace564]=20
> May 22 18:31:32 DD-WRT : =
/usr/lib/libutils.so[0x77c7f000](+0x00014b74)[0x77c93b74]=20
> May 22 18:31:32 DD-WRT : =3D=3D=3D Code:=20
> May 22 18:31:32 DD-WRT : 77a86040: 0000000c 00402025 2402107e =
0000000c 00402825 02003025 240210aa 0000000c=20
> May 22 18:31:32 DD-WRT : 77a86060: 14e0000c 00408025 24040003 =
02202825 00003025 24070010 24021063 0000000c=20
> May 22 18:31:32 DD-WRT : 77a86080: >02001025 8fb1010c 8fb00108 =
03e00008 27bd0110 8f8294d8 7c03e83b 00431021=20
> May 22 18:31:32 DD-WRT : 77a860a0: ac500000 1000fff0 2410ffff =
00000000 3c1c0017 279c1d70 0399e021 04800005=20
>=20
where i believe the ensuing segfault is due to something with the =
=E2=80=98failed=E2=80=99 authentication, causing the entire httpd daemon =
to crash.
it is not a debilitating issue to be honest, but i wanted to know if =
there is a better or more natural way to provide the credentials via the =
PAM interface.
i suspect the =E2=80=98solution=E2=80=99 i=E2=80=99m using (a very good =
one, i must say, considering the nature of the authentication) is part =
of the issue, but from what i have tried and read, using =
pam_{get,set}_item on the AUTHTOKs to authenticate a plaintext input =
will not work.
this is my /etc/pam.d/httpd:
> auth required pam_unix.so nullok try_first_pass
> account required pam_unix.so
> password required pam_unix.so=20
i have tried adding =E2=80=98likeauth=E2=80=99 to the first line, but =
that does not help.
is there a better solution? the only time the program crashes is due to =
this page, and this is the only time i have seen pam give this error.
thank you.
--Apple-Mail=_E4832AE8-3125-4406-8822-E34DEA4B51CB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">my current issue certainly feels like a continuation of an =
almost-fifteen year old post, so first let us distribute thy =
credit=E2=80=A6<div class=3D""><pre class=3D""></pre><pre =
class=3D""><blockquote type=3D"cite" class=3D""></blockquote><blockquote =
type=3D"cite" class=3D""><ul class=3D"">
<li class=3D""><em class=3D"">From</em>: Rafa Forcada <rforcada =
join-es com></li>
<li class=3D""><em class=3D"">To</em>: pam-list redhat com</li>
<li class=3D""><em class=3D"">Subject</em>: Re: understanding =
'likeauth'</li>
<li class=3D""><em class=3D"">Date</em>: Mon, 12 Jan 2004 17:08:52 +0100 =
(CET)</li></ul></blockquote><blockquote type=3D"cite" =
class=3D""><blockquote type=3D"cite" class=3D"">On Sun, 11 Jan 2004, =
Brian Jones wrote:
> Hi all,
>
> I've been trying to find a good explanation for exactly what the
> 'likeauth' parameter to the pam_unix module actually does, when
> (precisely) it should be used, etc.
>
> I've found a couple of places through google searches where this is
> discussed, but I'm still not sure if I get it. My understanding is =
that
> if you have pam_unix listed as 'sufficient' and another module =
under it
> listed as 'required', then 'likeauth' needs to be used to ensure =
that
> the value returned by the 'sectcred()' function of the *second* =
module
> is the one returned to the application (assuming, of course, that =
the
> second module succeeds, of course).
>
> This is confusing, because I though that if any part of the module
> failed, the module returns a failed status, and things move to the =
next
> module. This explanation seems to imply that multiple values are
> returned from pam_unix, one for 'auth()', and one for 'setcred()', =
and
> the failure of one doesn't mean the module fails? Is the module =
called
> twice or something? What's the order of operations in the (quite =
common)
> scenario of having:
>
> auth sufficient /lib/security/$ISA/pam_unix.so likeauth =
nullok
> auth required /lib/security/$ISA/pam_deny.so
>
> Why do I need 'likeauth' here? What happens if I remove it?
>
> Can anyone shed s'more light or give a better example of the
> consequences of using or not using likeauth?
>
</blockquote><br class=3D""></blockquote><blockquote type=3D"cite" =
class=3D"">Hi there!
If you check out the source code of pam_unix (pam_unix_auth.c), you will
find the answer.
When pam_unix is required for auth, pam calls 2 functions into it:
pam_sm_authenticate and pam_sm_setcred.
In my opinion, pam calls pam_sm_authenticate and pam_sm_setcred one =
after
another.
If you provide the 'likeauth' parameter, pam_sm_setcred returns the same =
value
as pam_sm_authenticate (this last one stores it), I think that is the =
reason
why the parameter is called 'likeauth': return the same value as =
pam_sm_authenticate.
I'm not sure about what is the real value returned to the pam library.
Does that mean that if pam_sm_authenticate fails and no 'likeauth' has
been specified, the returned value is 'success' because pam_sm_setcred
returns success?
--
__
_ __ __ _ / _| __ _
| '__/ _` | |_ / _` |
| | | (_| | _| (_| |
|_| __ _|_| __ _|
Rafa Forcada Mart=C3=ADnez
<a href=3D"mailto:rforcada" class=3D"">mailto:rforcada</a> join-es com
JOvenes INform=C3=A1ticos
<a href=3D"http://www.join-es.com" class=3D"">http://www.join-es.com</a>=
</blockquote></pre><div class=3D"">in my current setup, i=E2=80=99ve =
managed to make this legacy httpd application authenticate against pam =
in =E2=80=98normal=E2=80=99 situations.</div></div><div class=3D""><br =
class=3D""></div><div class=3D"">that is, when a user accesses the =
kernel=E2=80=99s router interface via 192.168.1.1, they must give their =
password which is then verified through PAM.</div><div class=3D""><br =
class=3D""></div><div class=3D"">i used this code here: <a =
href=3D"https://stackoverflow.com/a/5970078/1932859" =
class=3D"">https://stackoverflow.com/a/5970078/1932859</a> to parse =
the user input in the http header and pass it off to pam.</div><div =
class=3D""><br class=3D""></div><div class=3D"">amazingly this works =
quite well. and even when the password is changed via =E2=80=98passwd=E2=80=
=99 in shell, the interface will pick it up quite fast and consequently =
re-prompt for new credentials.</div><div class=3D""><br =
class=3D""></div><div class=3D"">there is one strange situation, =
however, when it comes to =E2=80=98demanding=E2=80=99 =
pages. </div><div class=3D""><br class=3D""></div><div class=3D"">on =
what i define as a =E2=80=98demanding page=E2=80=99, there are =
approximately 20+ interfaces, each with their own dynamically-generated =
svg graphic depicting the current throughput of each =
interface. </div><div class=3D""><br class=3D""></div><div =
class=3D"">presumably all of this information must be transmitted =
through httpd, but i am not sure.</div><div class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>-what i =
am sure of, however, is that only on this =E2=80=98demanding=E2=80=99 =
page do i get the following error thrown by pam:</div><div class=3D""><br =
class=3D""></div><span class=3D""></span><blockquote type=3D"cite" =
class=3D""><span class=3D"">May 22 18:31:32 DD-WRT httpd[536]: =
pam_unix(httpd:auth): auth could not identify password for [root]<br =
class=3D""></span><span class=3D""></span></blockquote><span =
class=3D""><blockquote type=3D"cite" class=3D"">May 22 18:31:32 DD-WRT =
httpd[536]: pam_unix(httpd:auth): auth could not identify password for =
[root]<br class=3D""></blockquote><div class=3D""><span class=3D""><br =
class=3D""></span></div>followed by this segfault in the program:<br =
class=3D""><blockquote type=3D"cite" class=3D"">May 22 18:31:32 DD-WRT : =
Caught SIGSEGV (11) sent by kernel in ??? <br class=3D"">May 22 =
18:31:32 DD-WRT : Thread 2373: httpd <br class=3D"">May 22 18:31:32 =
DD-WRT : =3D=3D=3D Context: <br class=3D"">May 22 18:31:32 DD-WRT : =
ZERO:00000000 AT:00000001 V0:00000000&nb=
sp; V1:00000001 A0:6677656e A=
1:00000001 <br class=3D"">May 22 18:31:32 DD-WRT =
: A2:00000010 A3:74600471 &nb=
sp;T0:00000001 T1:00000fa6 T2:00000000&n=
bsp; T3:006e7275 <br class=3D"">May 22 18:31:32 DD-WRT =
: T4:76dbae28 T5:77c28020 &nb=
sp;T6:004400b0 T7:746005b8 S0:746004b0&n=
bsp; S1:77adda30 <br class=3D"">May 22 18:31:32 DD-WRT =
: S2:746005b0 S3:74600470 &nb=
sp;S4:76dbb920 S5:00000000 S6:00409804&n=
bsp; S7:76dbb920 <br class=3D"">May 22 18:31:32 DD-WRT =
: T8:00000000 T9:77ad90e8 &nb=
sp;K0:7460049b K1:00000000 GP:77bf7e20&n=
bsp; SP:76dbaee8 <br class=3D"">May 22 18:31:32 DD-WRT =
: FP:76dbaf40 RA:77bb4484 <br =
class=3D"">May 22 18:31:32 DD-WRT : =3D=3D=3D Backtrace: <br =
class=3D"">May 22 18:31:32 DD-WRT : # [0x77bb442c]: ra offset =
44 <br class=3D"">May 22 18:31:32 DD-WRT : # [0x77bb4418]: stack =
size 48 <br class=3D"">May 22 18:31:32 DD-WRT : # [0x77bb45e8]: ra =
offset 36 <br class=3D"">May 22 18:31:32 DD-WRT : # [0x77bb45d0]: =
stack size 40 <br class=3D"">May 22 18:31:32 DD-WRT : # =
[0x77bfbb54]: ra offset 172 <br class=3D"">May 22 18:31:32 DD-WRT : =
# [0x77bfbb28]: stack size 176 <br class=3D"">May 22 18:31:32 =
DD-WRT : # [0x77b5768c]: stack size 32 <br class=3D"">May 22 =
18:31:32 DD-WRT : # [0x77b57678]: stack size 32 <br class=3D"">May =
22 18:31:32 DD-WRT : # [0x77b5761c]: stack size 32 <br class=3D"">May=
22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](+0x00160474)[0x77bb4474] <br =
class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](__libc_thread_freeres+0x00000058)[0x77bb461c]&n=
bsp;<br class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libpthread.so.0[0x77bf5000](+0x00006c84)[0x77bfbc84] <br =
class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](+0x001036ac)[0x77b576ac] <br =
class=3D"">May 22 18:31:32 DD-WRT : ???(+0)[0x77f9b030] <br =
class=3D"">May 22 18:31:32 DD-WRT : =3D=3D=3D Code: <br =
class=3D"">May 22 18:31:32 DD-WRT : 77bb4434: afb10020 =
afb0001c 1260001c 26700040 00602025 8f8394f0 ac400000 00641821 <br =
class=3D"">May 22 18:31:32 DD-WRT : 77bb4454: 24020001 =
8f9187ec a0620000 26720140 8e040000 00000000 10800009 00000000 <br =
class=3D"">May 22 18:31:32 DD-WRT : 77bb4474: >8c820000 0220c825 =
0320f809 ae020000 8e040000 00000000 1480fff9 00000000 <br =
class=3D"">May 22 18:31:32 DD-WRT : 77bb4494: 26100004 =
1650fff2 0220c825 0320f809 02602025 8fbc0010 00000000 8f8294e8 <br =
class=3D"">May 22 18:31:32 DD-WRT : Caught SIGABRT (6) sent by =
tkill <br class=3D"">May 22 18:31:32 DD-WRT : Thread 2374: =
httpd <br class=3D"">May 22 18:31:32 DD-WRT : =3D=3D=3D =
Context: <br class=3D"">May 22 18:31:32 DD-WRT : =
ZERO:00000000 AT:00000001 V0:00000000&nb=
sp; V1:74ffec00 A0:00000003 A=
1:74ffec00 <br class=3D"">May 22 18:31:32 DD-WRT =
: A2:00000000 A3:00000000 &nb=
sp;T0:00000000 T1:00000401 T2:00000001&n=
bsp; T3:77fa7000 <br class=3D"">May 22 18:31:32 DD-WRT =
: T4:00002000 T5:fffffffc &nb=
sp;T6:00100000 T7:00001072 S0:00000000&n=
bsp; S1:74ffec00 <br class=3D"">May 22 18:31:32 DD-WRT =
: S2:77bf4000 S3:00000010 &nb=
sp;S4:77ae4c70 S5:77f9a000 S6:00000002&n=
bsp; S7:00000002 <br class=3D"">May 22 18:31:32 DD-WRT =
: T8:77abf088 T9:77a85fb0 &nb=
sp;K0:00000010 K1:00000000 GP:77bf7e20&n=
bsp; SP:74ffeb78 <br class=3D"">May 22 18:31:32 DD-WRT =
: FP:74ffee10 RA:77a87754 <br =
class=3D"">May 22 18:31:32 DD-WRT : =3D=3D=3D Backtrace: <br =
class=3D"">May 22 18:31:32 DD-WRT : # [0x77a85fc0]: stack size =
272 <br class=3D"">May 22 18:31:32 DD-WRT : # [0x77a875e4]: ra =
offset 316 <br class=3D"">May 22 18:31:32 DD-WRT : # [0x77a875dc]: =
stack size 320 <br class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](gsignal+0x000000d0)[0x77a86080] <br =
class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](abort+0x00000184)[0x77a87754] <br =
class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](__libc_fatal+0x00000000)[0x77ace564] <br =
class=3D"">May 22 18:31:32 DD-WRT : =
/usr/lib/libutils.so[0x77c7f000](+0x00014b74)[0x77c93b74] <br =
class=3D"">May 22 18:31:32 DD-WRT : =3D=3D=3D Code: <br =
class=3D"">May 22 18:31:32 DD-WRT : 77a86040: 0000000c =
00402025 2402107e 0000000c 00402825 02003025 240210aa 0000000c <br =
class=3D"">May 22 18:31:32 DD-WRT : 77a86060: 14e0000c =
00408025 24040003 02202825 00003025 24070010 24021063 0000000c <br =
class=3D"">May 22 18:31:32 DD-WRT : 77a86080: >02001025 8fb1010c =
8fb00108 03e00008 27bd0110 8f8294d8 7c03e83b 00431021 <br =
class=3D"">May 22 18:31:32 DD-WRT : 77a860a0: ac500000 =
1000fff0 2410ffff 00000000 3c1c0017 279c1d70 0399e021 04800005 <br =
class=3D"">May 22 18:31:32 DD-WRT : Caught SIGABRT (6) sent by =
tkill <br class=3D"">May 22 18:31:32 DD-WRT : Thread 2370: =
httpd <br class=3D"">May 22 18:31:32 DD-WRT : =3D=3D=3D =
Context: <br class=3D"">May 22 18:31:32 DD-WRT : =
ZERO:00000000 AT:00000001 V0:00000000&nb=
sp; V1:7789fc00 A0:00000003 A=
1:7789fc00 <br class=3D"">May 22 18:31:32 DD-WRT =
: A2:00000000 A3:00000000 &nb=
sp;T0:00000000 T1:00000401 T2:77f99000&n=
bsp; T3:77fa7000 <br class=3D"">May 22 18:31:32 DD-WRT =
: T4:00002000 T5:fffffffc &nb=
sp;T6:00100000 T7:00001072 S0:00000000&n=
bsp; S1:7789fc00 <br class=3D"">May 22 18:31:32 DD-WRT =
: S2:77bf4000 S3:00000010 &nb=
sp;S4:77ae4c70 S5:77f99000 S6:00000002&n=
bsp; S7:00000002 <br class=3D"">May 22 18:31:32 DD-WRT =
: T8:77abf088 T9:77a85fb0 &nb=
sp;K0:00000010 K1:00000000 GP:77bf7e20&n=
bsp; SP:7789fb78 <br class=3D"">May 22 18:31:32 DD-WRT =
: FP:7789fe10 RA:77a87754 <br =
class=3D"">May 22 18:31:32 DD-WRT : =3D=3D=3D Backtrace: <br =
class=3D"">May 22 18:31:32 DD-WRT : # [0x77a85fc0]: stack size =
272 <br class=3D"">May 22 18:31:32 DD-WRT : # [0x77a875e4]: ra =
offset 316 <br class=3D"">May 22 18:31:32 DD-WRT : # [0x77a875dc]: =
stack size 320 <br class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](gsignal+0x000000d0)[0x77a86080] <br =
class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](abort+0x00000184)[0x77a87754] <br =
class=3D"">May 22 18:31:32 DD-WRT : =
/lib/libc.so.6[0x77a54000](__libc_fatal+0x00000000)[0x77ace564] <br =
class=3D"">May 22 18:31:32 DD-WRT : =
/usr/lib/libutils.so[0x77c7f000](+0x00014b74)[0x77c93b74] <br =
class=3D"">May 22 18:31:32 DD-WRT : =3D=3D=3D Code: <br =
class=3D"">May 22 18:31:32 DD-WRT : 77a86040: 0000000c =
00402025 2402107e 0000000c 00402825 02003025 240210aa 0000000c <br =
class=3D"">May 22 18:31:32 DD-WRT : 77a86060: 14e0000c =
00408025 24040003 02202825 00003025 24070010 24021063 0000000c <br =
class=3D"">May 22 18:31:32 DD-WRT : 77a86080: >02001025 8fb1010c =
8fb00108 03e00008 27bd0110 8f8294d8 7c03e83b 00431021 <br =
class=3D"">May 22 18:31:32 DD-WRT : 77a860a0: ac500000 =
1000fff0 2410ffff 00000000 3c1c0017 279c1d70 0399e021 04800005 <br =
class=3D""><br class=3D""></blockquote></span><span class=3D""><br =
class=3D""></span><div class=3D"">where i believe the ensuing segfault =
is due to something with the =E2=80=98failed=E2=80=99 authentication, =
causing the entire httpd daemon to crash.</div><div class=3D""><br =
class=3D""></div><div class=3D"">it is not a debilitating issue to be =
honest, but i wanted to know if there is a better or more natural way to =
provide the credentials via the PAM interface.</div><div class=3D""><br =
class=3D""></div><div class=3D"">i suspect the =E2=80=98solution=E2=80=99 =
i=E2=80=99m using (a very good one, i must say, considering the nature =
of the authentication) is part of the issue, but from what i have tried =
and read, using pam_{get,set}_item on the AUTHTOKs to authenticate a =
plaintext input will not work.</div><div class=3D""><br =
class=3D""></div><div class=3D"">this is my /etc/pam.d/httpd:</div><div =
class=3D""><br class=3D""></div><div class=3D""><div style=3D"margin: =
0px; font-size: 10px; font-family: Monaco; color: rgb(245, 245, 245); =
background-color: rgb(0, 0, 0);" class=3D""></div></div><span =
class=3D""><blockquote type=3D"cite" class=3D"">auth =
required pam_unix.so nullok =
try_first_pass<br class=3D"">account =
required pam_unix.so<br =
class=3D"">password required =
pam_unix.so <br class=3D""></blockquote><div =
class=3D""><span class=3D""><br class=3D""></span></div>i have tried =
adding =E2=80=98likeauth=E2=80=99 to the first line, but that does =
not help.</span><div class=3D""><br class=3D""></div><div class=3D"">is =
there a better solution? the only time the program crashes is due to =
this page, and this is the only time i have seen pam give this =
error.</div><div class=3D""><br class=3D""></div><div class=3D"">thank =
you.</div><div class=3D""><div class=3D""><span class=3D""><br =
class=3D""></span></div></div></body></html>=
--Apple-Mail=_E4832AE8-3125-4406-8822-E34DEA4B51CB--
--===============6598109320954472792==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Pam-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pam-list
--===============6598109320954472792==--