<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">my current issue certainly feels like a continuation of an almost-fifteen year old post, so first let us distribute thy credit…<div class=""><pre class=""></pre><pre class=""><blockquote type="cite" class=""></blockquote><blockquote type="cite" class=""><ul class=""> <li class=""><em class="">From</em>: Rafa Forcada <rforcada join-es com></li> <li class=""><em class="">To</em>: pam-list redhat com</li> <li class=""><em class="">Subject</em>: Re: understanding 'likeauth'</li> <li class=""><em class="">Date</em>: Mon, 12 Jan 2004 17:08:52 +0100 (CET)</li></ul></blockquote><blockquote type="cite" class=""><blockquote type="cite" class="">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=""></blockquote><blockquote type="cite" class="">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 <a href="mailto:rforcada" class="">mailto:rforcada</a> join-es com JOvenes INformáticos <a href="http://www.join-es.com" class="">http://www.join-es.com</a> </blockquote></pre><div class="">in my current setup, i’ve managed to make this legacy httpd application authenticate against pam in ‘normal’ situations.</div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">i used this code here: <a href="https://stackoverflow.com/a/5970078/1932859" class="">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=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">there is one strange situation, however, when it comes to ‘demanding’ pages. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">presumably all of this information must be transmitted through httpd, but i am not sure.</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>-what i am sure of, however, is that only on this ‘demanding’ page do i get the following error thrown by pam:</div><div class=""><br class=""></div><span class=""></span><blockquote type="cite" class=""><span class="">May 22 18:31:32 DD-WRT httpd[536]: pam_unix(httpd:auth): auth could not identify password for [root]<br class=""></span><span class=""></span></blockquote><span class=""><blockquote type="cite" class="">May 22 18:31:32 DD-WRT httpd[536]: pam_unix(httpd:auth): auth could not identify password for [root]<br class=""></blockquote><div class=""><span class=""><br class=""></span></div>followed by this segfault in the program:<br class=""><blockquote type="cite" class="">May 22 18:31:32 DD-WRT : Caught SIGSEGV (11) sent by kernel in ??? <br class="">May 22 18:31:32 DD-WRT : Thread 2373: httpd <br class="">May 22 18:31:32 DD-WRT : === Context: <br class="">May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 V1:00000001 A0:6677656e A1:00000001 <br class="">May 22 18:31:32 DD-WRT : A2:00000010 A3:74600471 T0:00000001 T1:00000fa6 T2:00000000 T3:006e7275 <br class="">May 22 18:31:32 DD-WRT : T4:76dbae28 T5:77c28020 T6:004400b0 T7:746005b8 S0:746004b0 S1:77adda30 <br class="">May 22 18:31:32 DD-WRT : S2:746005b0 S3:74600470 S4:76dbb920 S5:00000000 S6:00409804 S7:76dbb920 <br class="">May 22 18:31:32 DD-WRT : T8:00000000 T9:77ad90e8 K0:7460049b K1:00000000 GP:77bf7e20 SP:76dbaee8 <br class="">May 22 18:31:32 DD-WRT : FP:76dbaf40 RA:77bb4484 <br class="">May 22 18:31:32 DD-WRT : === Backtrace: <br class="">May 22 18:31:32 DD-WRT : # [0x77bb442c]: ra offset 44 <br class="">May 22 18:31:32 DD-WRT : # [0x77bb4418]: stack size 48 <br class="">May 22 18:31:32 DD-WRT : # [0x77bb45e8]: ra offset 36 <br class="">May 22 18:31:32 DD-WRT : # [0x77bb45d0]: stack size 40 <br class="">May 22 18:31:32 DD-WRT : # [0x77bfbb54]: ra offset 172 <br class="">May 22 18:31:32 DD-WRT : # [0x77bfbb28]: stack size 176 <br class="">May 22 18:31:32 DD-WRT : # [0x77b5768c]: stack size 32 <br class="">May 22 18:31:32 DD-WRT : # [0x77b57678]: stack size 32 <br class="">May 22 18:31:32 DD-WRT : # [0x77b5761c]: stack size 32 <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](+0x00160474)[0x77bb4474] <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](__libc_thread_freeres+0x00000058)[0x77bb461c] <br class="">May 22 18:31:32 DD-WRT : /lib/libpthread.so.0[0x77bf5000](+0x00006c84)[0x77bfbc84] <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](+0x001036ac)[0x77b576ac] <br class="">May 22 18:31:32 DD-WRT : ???(+0)[0x77f9b030] <br class="">May 22 18:31:32 DD-WRT : === Code: <br class="">May 22 18:31:32 DD-WRT : 77bb4434: afb10020 afb0001c 1260001c 26700040 00602025 8f8394f0 ac400000 00641821 <br class="">May 22 18:31:32 DD-WRT : 77bb4454: 24020001 8f9187ec a0620000 26720140 8e040000 00000000 10800009 00000000 <br class="">May 22 18:31:32 DD-WRT : 77bb4474: >8c820000 0220c825 0320f809 ae020000 8e040000 00000000 1480fff9 00000000 <br class="">May 22 18:31:32 DD-WRT : 77bb4494: 26100004 1650fff2 0220c825 0320f809 02602025 8fbc0010 00000000 8f8294e8 <br class="">May 22 18:31:32 DD-WRT : Caught SIGABRT (6) sent by tkill <br class="">May 22 18:31:32 DD-WRT : Thread 2374: httpd <br class="">May 22 18:31:32 DD-WRT : === Context: <br class="">May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 V1:74ffec00 A0:00000003 A1:74ffec00 <br class="">May 22 18:31:32 DD-WRT : A2:00000000 A3:00000000 T0:00000000 T1:00000401 T2:00000001 T3:77fa7000 <br class="">May 22 18:31:32 DD-WRT : T4:00002000 T5:fffffffc T6:00100000 T7:00001072 S0:00000000 S1:74ffec00 <br class="">May 22 18:31:32 DD-WRT : S2:77bf4000 S3:00000010 S4:77ae4c70 S5:77f9a000 S6:00000002 S7:00000002 <br class="">May 22 18:31:32 DD-WRT : T8:77abf088 T9:77a85fb0 K0:00000010 K1:00000000 GP:77bf7e20 SP:74ffeb78 <br class="">May 22 18:31:32 DD-WRT : FP:74ffee10 RA:77a87754 <br class="">May 22 18:31:32 DD-WRT : === Backtrace: <br class="">May 22 18:31:32 DD-WRT : # [0x77a85fc0]: stack size 272 <br class="">May 22 18:31:32 DD-WRT : # [0x77a875e4]: ra offset 316 <br class="">May 22 18:31:32 DD-WRT : # [0x77a875dc]: stack size 320 <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](gsignal+0x000000d0)[0x77a86080] <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](abort+0x00000184)[0x77a87754] <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](__libc_fatal+0x00000000)[0x77ace564] <br class="">May 22 18:31:32 DD-WRT : /usr/lib/libutils.so[0x77c7f000](+0x00014b74)[0x77c93b74] <br class="">May 22 18:31:32 DD-WRT : === Code: <br class="">May 22 18:31:32 DD-WRT : 77a86040: 0000000c 00402025 2402107e 0000000c 00402825 02003025 240210aa 0000000c <br class="">May 22 18:31:32 DD-WRT : 77a86060: 14e0000c 00408025 24040003 02202825 00003025 24070010 24021063 0000000c <br class="">May 22 18:31:32 DD-WRT : 77a86080: >02001025 8fb1010c 8fb00108 03e00008 27bd0110 8f8294d8 7c03e83b 00431021 <br class="">May 22 18:31:32 DD-WRT : 77a860a0: ac500000 1000fff0 2410ffff 00000000 3c1c0017 279c1d70 0399e021 04800005 <br class="">May 22 18:31:32 DD-WRT : Caught SIGABRT (6) sent by tkill <br class="">May 22 18:31:32 DD-WRT : Thread 2370: httpd <br class="">May 22 18:31:32 DD-WRT : === Context: <br class="">May 22 18:31:32 DD-WRT : ZERO:00000000 AT:00000001 V0:00000000 V1:7789fc00 A0:00000003 A1:7789fc00 <br class="">May 22 18:31:32 DD-WRT : A2:00000000 A3:00000000 T0:00000000 T1:00000401 T2:77f99000 T3:77fa7000 <br class="">May 22 18:31:32 DD-WRT : T4:00002000 T5:fffffffc T6:00100000 T7:00001072 S0:00000000 S1:7789fc00 <br class="">May 22 18:31:32 DD-WRT : S2:77bf4000 S3:00000010 S4:77ae4c70 S5:77f99000 S6:00000002 S7:00000002 <br class="">May 22 18:31:32 DD-WRT : T8:77abf088 T9:77a85fb0 K0:00000010 K1:00000000 GP:77bf7e20 SP:7789fb78 <br class="">May 22 18:31:32 DD-WRT : FP:7789fe10 RA:77a87754 <br class="">May 22 18:31:32 DD-WRT : === Backtrace: <br class="">May 22 18:31:32 DD-WRT : # [0x77a85fc0]: stack size 272 <br class="">May 22 18:31:32 DD-WRT : # [0x77a875e4]: ra offset 316 <br class="">May 22 18:31:32 DD-WRT : # [0x77a875dc]: stack size 320 <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](gsignal+0x000000d0)[0x77a86080] <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](abort+0x00000184)[0x77a87754] <br class="">May 22 18:31:32 DD-WRT : /lib/libc.so.6[0x77a54000](__libc_fatal+0x00000000)[0x77ace564] <br class="">May 22 18:31:32 DD-WRT : /usr/lib/libutils.so[0x77c7f000](+0x00014b74)[0x77c93b74] <br class="">May 22 18:31:32 DD-WRT : === Code: <br class="">May 22 18:31:32 DD-WRT : 77a86040: 0000000c 00402025 2402107e 0000000c 00402825 02003025 240210aa 0000000c <br class="">May 22 18:31:32 DD-WRT : 77a86060: 14e0000c 00408025 24040003 02202825 00003025 24070010 24021063 0000000c <br class="">May 22 18:31:32 DD-WRT : 77a86080: >02001025 8fb1010c 8fb00108 03e00008 27bd0110 8f8294d8 7c03e83b 00431021 <br class="">May 22 18:31:32 DD-WRT : 77a860a0: ac500000 1000fff0 2410ffff 00000000 3c1c0017 279c1d70 0399e021 04800005 <br class=""><br class=""></blockquote></span><span class=""><br class=""></span><div class="">where i believe the ensuing segfault is due to something with the ‘failed’ authentication, causing the entire httpd daemon to crash.</div><div class=""><br class=""></div><div class="">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=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">this is my /etc/pam.d/httpd:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 10px; font-family: Monaco; color: rgb(245, 245, 245); background-color: rgb(0, 0, 0);" class=""></div></div><span class=""><blockquote type="cite" class="">auth required pam_unix.so nullok try_first_pass<br class="">account required pam_unix.so<br class="">password required pam_unix.so <br class=""></blockquote><div class=""><span class=""><br class=""></span></div>i have tried adding ‘likeauth’ to the first line, but that does not help.</span><div class=""><br class=""></div><div class="">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=""><br class=""></div><div class="">thank you.</div><div class=""><div class=""><span class=""><br class=""></span></div></div></body></html>