shibd segfault when checking configuration

Guillaume Rousse guillaume.rousse at renater.fr
Mon Nov 28 13:38:06 UTC 2022


On a CentOS Stream 8, using packages provided by the Shibboleth foundation:

$ sudo -u shibd shibd -tc /etc/shibboleth/shibboleth2.xml
overall configuration is loadable, check console or log for non-fatal 
problems
Erreur de segmentation

gdb shows the error happens while checking cached individual metadata 
entries:
t#0  0x00007fcef48ed67e in 
shibsp::DynamicMetadataProvider::FolderCallback (pathname=0x7fcec80c65e0 
"/var/cache/shibboleth/fer/292ddbd82228f13831c6526e003f0d07e171e80b.xml", 
stat_buf=..., data=0x55b6a98c7a70)
     at metadata/DynamicMetadataProvider.cpp:481
481	                me->doFilters(&bc, *entity);
[Current thread is 1 (Thread 0x7fcedb7fe700 (LWP 438747))]
...
(gdb) bt full
#0  0x00007fcef48ed67e in 
shibsp::DynamicMetadataProvider::FolderCallback (pathname=0x7fcec80c65e0 
"/var/cache/shibboleth/fer/292ddbd82228f13831c6526e003f0d07e171e80b.xml", 
stat_buf=..., data=0x55b6a98c7a70)
     at metadata/DynamicMetadataProvider.cpp:481
         bc = <incomplete type>
         entity = {_M_ptr = 0x7fcec8046290}
         thisFileEntry = <incomplete type>
         me = <optimized out>
#1  0x00007fcef25a1e11 in xmltooling::DirectoryWalker::_walk(char 
const*, void (* const&)(char const*, stat&, void*), void*, char const*, 
char const*) const () from /usr/lib64/libxmltooling.so.10
No symbol table info available.
#2  0x00007fcef48ed37f in xmltooling::DirectoryWalker::walk 
(endsWith=0x0, startsWith=0x0, callback_data=0x55b6a98c7a70,
     callback_fn=@0x7fcedb7fdc58: 0x7fcef48ed4d0 
<shibsp::DynamicMetadataProvider::FolderCallback(char const*, stat&, 
void*)>, this=0x7fcedb7fdc60) at /usr/include/c++/8/bits/basic_string.h:2294
No locals.
#3  shibsp::DynamicMetadataProvider::init_fn (pv=0x55b6a98c7a70) at 
metadata/DynamicMetadataProvider.cpp:463
         walker = <incomplete type>
         me = 0x55b6a98c7a70
#4  0x00007fcef3d571ca in start_thread () from /usr/lib64/libpthread.so.0
No symbol table info available.
#5  0x00007fcef1721e73 in clone () from /usr/lib64/libc.so.6
No symbol table info available.

Here is the corresponding configuration for this metadata provider, 
using MDQ, but not any filter:
<MetadataProvider type="MDQ" cacheDirectory="fer" 
baseUrl="https://mdq.federation.renater.fr/fer">
     <TrustEngine type="StaticPKIX" 
certificate="/etc/pki/tls/certs/usertrust_rsa_certification_authority.crt"/>
</MetadataProvider>

It's reproductible systematically on our production cluster (with many 
cached entries), but absolutly not in other environments (with less 
cached entries). The XML file in the backtrace is different everytime, 
but the cache directory is the same. I checked implied files for XML 
syntax problems, or permission issues, without any result.

Fortunatly, there is no problem when restarting shibd, but that's a bit 
painful. And I have no clue how to investigate further.

Regards.
-- 
Guillaume Rousse
Direction des Services Applicatifs
RENATER - Paris
Tel: +33 1 53 94 20 45
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2258 bytes
Desc: Signature cryptographique S/MIME
URL: <http://shibboleth.net/pipermail/users/attachments/20221128/cfcdf62c/attachment.p7s>


More information about the users mailing list