[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: understanding 'likeauth'



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.

i used this code here: 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]