my current issue certainly feels like a continuation of an almost-fifteen year old post, so first let us distribute thy credit…
- From: Rafa Forcada <rforcada join-es com>
- To: pam-list redhat com
- Subject: Re: understanding 'likeauth'
- Date: Mon, 12 Jan 2004 17:08:52 +0100 (CET)
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?
>
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ínez
mailto:rforcada join-es com
JOvenes INformáticos
http://www.join-es.com
in my current setup, i’ve managed to make this legacy httpd application authenticate against pam in ‘normal’ situations.
that is, when a user accesses the kernel’s router interface via 192.168.1.1, they must give their password which is then verified through PAM.
amazingly this works quite well. and even when the password is changed via ‘passwd’ 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 ‘demanding’ pages.
on what i define as a ‘demanding page’, there are approximately 20+ interfaces, each with their own dynamically-generated svg graphic depicting the current throughput of each interface.
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 ‘demanding’ 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 ???
May 22 18:31:32 DD-WRT : Thread 2373: httpd
May 22 18:31:32 DD-WRT : === Context:
May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 V1:00000001 A0:6677656e A1:00000001
May 22 18:31:32 DD-WRT : A2:00000010 A3:74600471 T0:00000001 T1:00000fa6 T2:00000000 T3:006e7275
May 22 18:31:32 DD-WRT : T4:76dbae28 T5:77c28020 T6:004400b0 T7:746005b8 S0:746004b0 S1:77adda30
May 22 18:31:32 DD-WRT : S2:746005b0 S3:74600470 S4:76dbb920 S5:00000000 S6:00409804 S7:76dbb920
May 22 18:31:32 DD-WRT : T8:00000000 T9:77ad90e8 K0:7460049b K1:00000000 GP:77bf7e20 SP:76dbaee8
May 22 18:31:32 DD-WRT : FP:76dbaf40 RA:77bb4484
May 22 18:31:32 DD-WRT : === Backtrace:
May 22 18:31:32 DD-WRT : # [0x77bb442c]: ra offset 44
May 22 18:31:32 DD-WRT : # [0x77bb4418]: stack size 48
May 22 18:31:32 DD-WRT : # [0x77bb45e8]: ra offset 36
May 22 18:31:32 DD-WRT : # [0x77bb45d0]: stack size 40
May 22 18:31:32 DD-WRT : # [0x77bfbb54]: ra offset 172
May 22 18:31:32 DD-WRT : # [0x77bfbb28]: stack size 176
May 22 18:31:32 DD-WRT : # [0x77b5768c]: stack size 32
May 22 18:31:32 DD-WRT : # [0x77b57678]: stack size 32
May 22 18:31:32 DD-WRT : # [0x77b5761c]: stack size 32
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](+0x00160474)[0x77bb4474]
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](__libc_thread_freeres+0x00000058)[0x77bb461c]
May 22 18:31:32 DD-WRT : /lib/libpthread.so.0[0x77bf5000](+0x00006c84)[0x77bfbc84]
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](+0x001036ac)[0x77b576ac]
May 22 18:31:32 DD-WRT : ???(+0)[0x77f9b030]
May 22 18:31:32 DD-WRT : === Code:
May 22 18:31:32 DD-WRT : 77bb4434: afb10020 afb0001c 1260001c 26700040 00602025 8f8394f0 ac400000 00641821
May 22 18:31:32 DD-WRT : 77bb4454: 24020001 8f9187ec a0620000 26720140 8e040000 00000000 10800009 00000000
May 22 18:31:32 DD-WRT : 77bb4474: >8c820000 0220c825 0320f809 ae020000 8e040000 00000000 1480fff9 00000000
May 22 18:31:32 DD-WRT : 77bb4494: 26100004 1650fff2 0220c825 0320f809 02602025 8fbc0010 00000000 8f8294e8
May 22 18:31:32 DD-WRT : Caught SIGABRT (6) sent by tkill
May 22 18:31:32 DD-WRT : Thread 2374: httpd
May 22 18:31:32 DD-WRT : === Context:
May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 V1:74ffec00 A0:00000003 A1:74ffec00
May 22 18:31:32 DD-WRT : A2:00000000 A3:00000000 T0:00000000 T1:00000401 T2:00000001 T3:77fa7000
May 22 18:31:32 DD-WRT : T4:00002000 T5:fffffffc T6:00100000 T7:00001072 S0:00000000 S1:74ffec00
May 22 18:31:32 DD-WRT : S2:77bf4000 S3:00000010 S4:77ae4c70 S5:77f9a000 S6:00000002 S7:00000002
May 22 18:31:32 DD-WRT : T8:77abf088 T9:77a85fb0 K0:00000010 K1:00000000 GP:77bf7e20 SP:74ffeb78
May 22 18:31:32 DD-WRT : FP:74ffee10 RA:77a87754
May 22 18:31:32 DD-WRT : === Backtrace:
May 22 18:31:32 DD-WRT : # [0x77a85fc0]: stack size 272
May 22 18:31:32 DD-WRT : # [0x77a875e4]: ra offset 316
May 22 18:31:32 DD-WRT : # [0x77a875dc]: stack size 320
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](gsignal+0x000000d0)[0x77a86080]
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](abort+0x00000184)[0x77a87754]
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](__libc_fatal+0x00000000)[0x77ace564]
May 22 18:31:32 DD-WRT : /usr/lib/libutils.so[0x77c7f000](+0x00014b74)[0x77c93b74]
May 22 18:31:32 DD-WRT : === Code:
May 22 18:31:32 DD-WRT : 77a86040: 0000000c 00402025 2402107e 0000000c 00402825 02003025 240210aa 0000000c
May 22 18:31:32 DD-WRT : 77a86060: 14e0000c 00408025 24040003 02202825 00003025 24070010 24021063 0000000c
May 22 18:31:32 DD-WRT : 77a86080: >02001025 8fb1010c 8fb00108 03e00008 27bd0110 8f8294d8 7c03e83b 00431021
May 22 18:31:32 DD-WRT : 77a860a0: ac500000 1000fff0 2410ffff 00000000 3c1c0017 279c1d70 0399e021 04800005
May 22 18:31:32 DD-WRT : Caught SIGABRT (6) sent by tkill
May 22 18:31:32 DD-WRT : Thread 2370: httpd
May 22 18:31:32 DD-WRT : === Context:
May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 V1:7789fc00 A0:00000003 A1:7789fc00
May 22 18:31:32 DD-WRT : A2:00000000 A3:00000000 T0:00000000 T1:00000401 T2:77f99000 T3:77fa7000
May 22 18:31:32 DD-WRT : T4:00002000 T5:fffffffc T6:00100000 T7:00001072 S0:00000000 S1:7789fc00
May 22 18:31:32 DD-WRT : S2:77bf4000 S3:00000010 S4:77ae4c70 S5:77f99000 S6:00000002 S7:00000002
May 22 18:31:32 DD-WRT : T8:77abf088 T9:77a85fb0 K0:00000010 K1:00000000 GP:77bf7e20 SP:7789fb78
May 22 18:31:32 DD-WRT : FP:7789fe10 RA:77a87754
May 22 18:31:32 DD-WRT : === Backtrace:
May 22 18:31:32 DD-WRT : # [0x77a85fc0]: stack size 272
May 22 18:31:32 DD-WRT : # [0x77a875e4]: ra offset 316
May 22 18:31:32 DD-WRT : # [0x77a875dc]: stack size 320
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](gsignal+0x000000d0)[0x77a86080]
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](abort+0x00000184)[0x77a87754]
May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](__libc_fatal+0x00000000)[0x77ace564]
May 22 18:31:32 DD-WRT : /usr/lib/libutils.so[0x77c7f000](+0x00014b74)[0x77c93b74]
May 22 18:31:32 DD-WRT : === Code:
May 22 18:31:32 DD-WRT : 77a86040: 0000000c 00402025 2402107e 0000000c 00402825 02003025 240210aa 0000000c
May 22 18:31:32 DD-WRT : 77a86060: 14e0000c 00408025 24040003 02202825 00003025 24070010 24021063 0000000c
May 22 18:31:32 DD-WRT : 77a86080: >02001025 8fb1010c 8fb00108 03e00008 27bd0110 8f8294d8 7c03e83b 00431021
May 22 18:31:32 DD-WRT : 77a860a0: ac500000 1000fff0 2410ffff 00000000 3c1c0017 279c1d70 0399e021 04800005
where i believe the ensuing segfault is due to something with the ‘failed’ 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 ‘solution’ i’m 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
i have tried adding ‘likeauth’ 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. |
