understanding 'likeauth'
Gagan Sidhu
broly at mac.com
Wed May 23 01:06:44 UTC 2018
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 <mailto:rforcada> join-es com
>
> JOvenes INformáticos
> http://www.join-es.com <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.
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 ‘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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pam-list/attachments/20180522/d4a3f483/attachment.htm>
More information about the Pam-list
mailing list