<div dir="ltr">Hi Scott,<div><br></div><div>There were few missing links while I had communicated the my product design to you last time.</div><div>The .so which I am adding will be part of the a module (e.g. webauth) of our so called web-server.</div>
<div>shibd is up and running fine on the same box.</div><div><br></div><div>Current Problem:</div><div>==============</div><div>Our webserver and most of its code is written in C.</div><div>For building shibboleth-sp, I have written a wrapper with "extern" (for c++) to call it from webauth module.<br>
</div><div>While I am trying to call shib_child_init for initializing the client portion of shibboleth library, but it is crashing at following location inside <b>"instantiate"</b>.</div><div>However, when I ran the same code for initializing the library independently from a separate program, the initialization happens fine.</div>
<div>The differences are:</div><div>1) the independent program is built using g++, and linked to <b>libshibsp.so</b> whereas for our module we are using gcc along with libstdc++.</div><div>2) the independent program is linked to <b>libshibsp.so</b> whereas webserver program binary is linked to the wrapper<b> lib</b><span style="background-color:rgb(238,238,238)"><font color="#0000ff"><b>my</b></font></span><b>shibsp.so </b>+ other shibboleth libraries.</div>
<div>3) ldd portion of webserver binary shows two differenct versions of libstdc++.so whereas the working independent binary shows only libstdc++.so.6</div><div><div><br></div><div>[root@105] # ldd webauthbin | grep libstdc++*</div>
<div><span class="" style="white-space:pre"> </span>libstdc++.so.6 => /home/product/code/firmware/current/lib64/libstdc++.so.6 (0x00007f66f631d000)</div><div><span class="" style="white-space:pre"> </span>libstdc++.so.5 => /usr/lib64/libstdc++.so.5 (0x00007f66f4fee000)</div>
</div><div><br></div><div><div>[root@105] # ldd a.out | grep libstdc++*</div><div><span class="" style="white-space:pre"> </span>libstdc++.so.6 => /home/product/code/firmware/current/lib64/libstdc++.so.6 (0x00007f53da8f0000)</div>
</div><div><br></div><div>Could this libstdc++.so be a problem for the follwoing crash ? if no, then, what else could be ?</div><div><br></div><div>Despite of spending good amount of time in debugging, I am unable to find the solution for the same, thus asking you.<br>
</div><div><br></div><div>shib_child_init portion</div><div>================</div><div><div> bool shib_child_init()</div><div> {</div><div><span class="" style="white-space:pre"> </span>g_Config=&SPConfig::getConfig();<br>
</div><div> <span class="" style="white-space:pre"> </span>g_Config->setFeatures(</div><div> SPConfig::Listener |</div><div> SPConfig::Caching |</div><div> SPConfig::RequestMapping |</div><div> SPConfig::InProcess |</div>
<div> SPConfig::Logging |</div><div> SPConfig::Handlers</div><div> );</div><div><br></div><div> if (!g_Config->init(g_szSchemaDir, g_szPrefix)) { }</div><div><br></div><div> try {<br></div>
<div> if (!<b>g_Config->instantiate(g_szSHIBConfig, true)</b>)</div><div> throw runtime_error("unknown error");</div><div> }</div><div> catch (std::exception& ex) { }</div></div>
<div>}</div><div><br></div><div><br></div><div>Crash:</div><div>=====</div><div><div>In function PMemLowWaterMarkInit ...</div><div>*** glibc detected *** /mail/data/product/code/firmware/<a href="http://7.8.0.010/bin64/stm">7.8.0.010/bin64/stm</a>: <b>munmap_chunk()</b>: invalid pointer: 0x00007f4bcc1a8478 ***</div>
<div>======= Backtrace: =========</div><div>/lib64/libc.so.6[0x7f4bda59b1b8]</div><div>/home/product/code/firmware/current/lib64/libstdc++.so.6(_ZNSsD1Ev+0x3d)[0x7f4bd7ced53d]</div><div>/home/bws/code/firmware/current/lib64/liblog4shib.so.1(_ZN8log4shib24PropertyConfiguratorImpl17configureCategoryERKSs+0x8d7)[0x7f4bd40b272d]</div>
<div>/home/bws/code/firmware/current/lib64/liblog4shib.so.1(_ZN8log4shib24PropertyConfiguratorImpl11doConfigureERSi+0x74)[0x7f4bd40b390e]</div><div>/home/bws/code/firmware/current/lib64/liblog4shib.so.1(_ZN8log4shib24PropertyConfiguratorImpl11doConfigureERKSs+0x32c)[0x7f4bd40b1dd0]</div>
<div>/home/bws/code/firmware/current/lib64/liblog4shib.so.1(_ZN8log4shib20PropertyConfigurator9configureERKSs+0x2e)[0x7f4bd40aef70]</div><div>/home/bws/code/firmware/current/lib64/libxmltooling.so.6(_ZN10xmltooling24XMLToolingInternalConfig10log_configEPKc+0x31f)[0x7f4bd4d67bef]</div>
<div>/home/bws/code/firmware/current/lib64/libshibsp.so.6[0x7f4bd60f0bf9]</div><div>/home/bws/code/firmware/current/lib64/libshibsp.so.6[0x7f4bd60f3542]</div><div>/home/bws/code/firmware/current/lib64/libshibsp.so.6[0x7f4bd60d87cc]</div>
</div><div>....</div><div><div>(gdb) bt</div><div>#0 0x00007f4bda55929b in raise () from /lib64/libc.so.6</div><div>#1 0x00007f4bda55a7f3 in abort () from /lib64/libc.so.6</div><div>#2 0x00007f4bda595c28 in __libc_message () from /lib64/libc.so.6</div>
<div>#3 0x00007f4bda59b1b8 in malloc_printerr () from /lib64/libc.so.6</div><div>#4 0x00007f4bd7ced53d in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string ()</div><div>
from /home/product/code/firmware/current/lib64/libstdc++.so.6</div><div>#5 0x00007f4bd40b272d in log4shib::PropertyConfiguratorImpl::configureCategory (this=0x7fff321c44b0, categoryName=@0x7f4bcc053d18)</div><div> at PropertyConfiguratorImpl.cpp:171</div>
<div>#6 0x00007f4bd40b390e in log4shib::PropertyConfiguratorImpl::doConfigure (this=0x7fff321c44b0, in=@0x7fff321c4230)</div><div> at PropertyConfiguratorImpl.cpp:88</div><div>#7 0x00007f4bd40b1dd0 in log4shib::PropertyConfiguratorImpl::doConfigure (this=0x7fff321c44b0, initFileName=@0x7fff321c4560)</div>
<div> at PropertyConfiguratorImpl.cpp:72</div><div>#8 0x00007f4bd40aef70 in log4shib::PropertyConfigurator::configure (initFileName=@0x7fff321c4560) at PropertyConfigurator.cpp:17</div><div>#9 0x00007f4bd4d67bef in xmltooling::XMLToolingInternalConfig::log_config (this=0x7f4bd514b500, config=0x7f4bcc07bf28 "native.logger")</div>
<div> at XMLToolingConfig.cpp:350</div><div>#10 0x00007f4bd60f0bf9 in XMLConfigImpl (this=0x7f4bcc301620, e=0x7f4bcc0784b0, first=true, outer=0x7f4bcc0608c0, log=@0x7f4bcc0010c0)</div><div> at impl/XMLServiceProvider.cpp:2009</div>
<div>#11 0x00007f4bd60f3542 in background_load (this=0x7f4bcc0608c0) at impl/XMLServiceProvider.cpp:2371</div><div>#12 0x00007f4bd60d87cc in init (this=0x7f4bcc0608c0) at impl/XMLServiceProvider.cpp:341</div><div>#13 0x00007f4bd5fe2d62 in shibsp::SPConfig::instantiate (this=0x7f4bd64dff60, config=0x7f4bd61d1430 "shibboleth2.xml", rethrow=true)</div>
<div> at SPConfig.cpp:447</div><div>#14 0x00007f4bd8a88668 in shib_child_init () at wafsp.cpp:265</div><div>#15 0x000000000041669b in AppStart (argc=4, argv=0x7fff321c5208, ExtraOptionHandler=0, extraOpts=0x0) at ncappmain.c:421</div>
<div>#16 0x000000000040abeb in main (argc=4, argv=0x7fff321c5208) at cachesysinit.c:94</div></div><div><br></div><div>Thanks a lot in advance for your support.</div><div><br></div><div>Regards,</div><div>Amit Thukral</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 6:46 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 7/9/13 9:24 AM, "Amit Thukral" <<a href="mailto:amit.thukral403@gmail.com">amit.thukral403@gmail.com</a>> wrote:<br>
<br>
>[athukral]: I have a configuration layer already implemented which is<br>
>specific to our product so thats why i did not provide those details<br>
>here. The "shib_check_user" function<br>
> is part of a .so which is linked to our process "stm" which has the<br>
>configuration layer already in it.<br>
<br>
</div>If you want to use the SP you have to be subordinate to it. The Apache<br>
module isn't something that acts independently and then sends messages to<br>
shibd to do a subset of things.<br>
<br>
Rather, the module is subordinate to the SP as a whole and the core of the<br>
system is the ServiceProvider class in libshibsp which runs various<br>
actions against a request that supports the SPRequest interface. The job<br>
of the module is to get the shibsp library started up with its<br>
configuration and then expose the Apache internals via the SPRequest<br>
interface when requests come into Apache.<br>
<br>
Then it is meant to call the relevant ServiceProvider::doXXX methods at<br>
appropriate times.<br>
<br>
You can have all the separate configuration you want but you still must<br>
instantiate the SP configuration object as part of your configuration<br>
activity. The Apache module does that in various ways due to Apache<br>
version differences, but Apache provides hooks for that to happen at the<br>
right times, and anything else must also, or it won't fit well.<br>
<div class="im"><br>
> I went through an apache tutorial on "adding a module to apache" and<br>
>understood what you meant by configuration layer.<br>
> I understood that this configuration is specific to what directory is<br>
>being accessed and what rules etc. should be governing the various<br>
>operations etc.<br>
<br>
</div>That's only part of the picture, other settings are global and influence<br>
how the library runtime is configured, such as overriding the config file<br>
path.<br>
<div class="im"><br>
> I have all that configuration information which is passed on from my<br>
>device but I don't know the order in which I should call the shibboleth<br>
>APIs etc.<br>
> to make the basic startup happen.<br>
<br>
</div>The Apache or IIS modules illustrate how that happens.<br>
<div class="im"><br>
> Similarly, I did not know what all configuration I really needed from<br>
>shibboleth2.xml for basic startup.<br>
>Since, apache doesn't need some of them to come from shibboleth2.xml<br>
>so I completely missed them on my another reference setup. Some of them<br>
>apache picks up from httpd.conf.<br>
<br>
</div>That's a special feature that is best ignored in the initial stage of<br>
getting something working. All of the configuration of how requests get<br>
handled can be left to the RequestMap. Later, it may be possible to<br>
enhance things by building something more advanced that can link local<br>
commands that control content rules to the RequestMap interface. That's<br>
what's inside the Apache module.<br>
<br>
The SP requires that all of that information be exposed through the<br>
RequestMap API. You cannot provide the information in any other way. Even<br>
the Apache commands work that way.<br>
<div class="im"><br>
> 1) <RequestMapper> - to map various requests to various application-ids.<br>
<br>
</div>Not just application-ids. Every property associated with a request.<br>
<div class="im"><br>
> 2) <InProcess> for starting up the native logger and if any .so to be<br>
>loaded dynamically.<br>
>Is there anything else apart from above that I would need to provide in<br>
><SPConfig> to make basic startup work ?<br>
<br>
</div>You can't pick and choose. You need to instantiate the entire SP runtime,<br>
you don't process individual sections of the file.<br>
<div class="im"><br>
>3) have not implemented anything similar to ApacheRequestMapper class.<br>
<br>
</div>That's optional (and see above, I wouldn't worry about it initially). But<br>
you cannot make your native content configuration work with the SP unless<br>
you bridge to it through that kind of class.<br>
<div class="im"><br>
> what functions I should be calling to process the incoming request ?<br>
<br>
</div>First you need to ensure that the incoming request is wrapped in something<br>
that implements SPRequest by subclassing AbstractSPRequest and adding the<br>
custom code needed.<br>
<br>
Then you have to call doAuthentication, doExport, doAuthorization, and<br>
doHandler in appropriate places, the latter being the way requests to the<br>
/Shibboleth.sso virtual URLs are dispatched.<br>
<br>
You can see all of those being called in the Apache module in particular<br>
Apache hooks.<br>
<br>
The doAuthentication/doExport methods are the core work done for each<br>
request in the check_user hook. The doAuthorization method allows the SP's<br>
pluggable access control layer to run in the Apache check_access hook.<br>
<div class="im"><br>
>[athukral]: I am going through mod_shib.cpp and i believe whatever is<br>
>being done regarding session/user mgmt etc. is already done in my WAF's<br>
>configuration layer and I can handle those things there.<br>
<br>
</div>The SP doesn't function without doing its own session management, that's<br>
what most of its code is for. If I could have used an existing session,<br>
the code would look nothing like it does now.<br>
<div class="im"><br>
>In above sentence by "different<br>
>API" do you mean the API other than Apache, Adfs, IIS etc. for which the<br>
>supported code is already there ?<br>
<br>
</div>I mean whatever proprietary API your web server uses to support modules.<br>
<br>
The modules don't do anything fundamental except handle startup/shutdown,<br>
shim a custom API into the SPRequest interface, and then invoke the<br>
ServiceProvider doXXX methods at appropriate points in the request flow.<br>
<br>
The IIS module is much shorter than the Apache module because the Apache<br>
module adds two major pieces of work:<br>
<br>
- supporting Apache commands via the RequestMap API<br>
- authorization<br>
<br>
But those are optional additions to the basic requirements.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
<br>
</font></span></blockquote></div><br></div>