italia/spid-shibboleth-proxy-docker

mod_shib - child pid 2561 exit signal Segmentation fault (11), possible coredump

Opened this issue · 13 comments

Fabiomad85 commented

Buonasera,

sto effettuando una migrazione dalla versione 0.4.0 alla versione 1.1.0 dello spid-proxy.

Ho effettuato alcune configurazioni relative al file z20-auth-proxy.conf.prod

Caricando l'immagine personalizzata nel registry privato però ho osservato che l'orchestrator di Azure non avviava il servizio.

2019-03-08 08:55:55.227 ERROR - Container spidauth-as-prod-app_0 for site spidauth-as-prod-app has exited, failing site start 2019-03-08 08:55:55.237 ERROR - Container spidauth-as-prod-app_0 didn't respond to HTTP pings on port: 80, failing site start. See container logs for debugging.

Cercando di capirne la causa, ho indagato all'interno dei log del container aumentando il livello di verbosità dei log a trace8 e nel error.log di apache emerge il fatto che apache continua a fare il respawn
fino a che l'orchestrator dopo 5 minuti fermail processo.

[Fri Mar 08 11:35:55.179564 2019] [mpm_prefork:notice] [pid 102] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.4.16 configured -- resuming normal operations [Fri Mar 08 11:35:55.185197 2019] [core:notice] [pid 102] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Fri Mar 08 11:35:57.201959 2019] [core:notice] [pid 102] AH00051: child pid 103 exit signal Segmentation fault (11), possible coredump in /etc/httpd [Fri Mar 08 11:35:57.202776 2019] [core:notice] [pid 102] AH00051: child pid 104 exit signal Segmentation fault (11), possible coredump in /etc/httpd

Ho cercato di avere una copia del core dump, senza successo. Ho provato a collegare gdb al proceso di apache, ma apache non aveva i flag di debug e quindi niente risultati.

Ho provato ad utilizzare debuginfo-install, ma nessun risultato significativo.

Cercando di approcciare il problema in maniera diversa, ho disabilitato tutti i moduli di apache, avviandoli man mano.

Alla fine ho osservato che disabilitando il mod_shib il container parte correttamente ( senza però la funzionalità shibboleth ovviamente ). Riattivandolo invece, il problema veniva replicato.

Però caso avete avuto ancora questo tipo di problematica?
Grazie

psmiraglia commented

Ciao @Fabiomad85

questa e' la configurazione che ottengo facendo un build senza cache del container alla versione 1.1.0.

[root@2eac1a6fe684 tmp]# date
Fri Mar  8 20:38:43 UTC 2019

[root@2eac1a6fe684 tmp]# cat /etc/redhat-release 
CentOS Linux release 7.6.1810 (Core) 

[root@2eac1a6fe684 httpd]# yum list installed | grep -P "(httpd|shib|ssl)" | sort
httpd-tools.x86_64                      2.4.6-88.el7.centos          @base      
httpd.x86_64                            2.4.6-88.el7.centos          @base      
libcurl-openssl.x86_64                  7.63.0-1.1                   @shibboleth
liblog4shib2.x86_64                     2.0.0-3.1                    @shibboleth
libsaml10.x86_64                        3.0.0-1.2                    @shibboleth
libxerces-c-3_2.x86_64                  3.2.1-1.1                    @shibboleth
libxml-security-c20.x86_64              2.0.2-3.1                    @shibboleth
libxmltooling8.x86_64                   3.0.3-5.1                    @shibboleth
mod_ssl.x86_64                          1:2.4.6-88.el7.centos        @base      
opensaml-schemas.x86_64                 3.0.0-1.2                    @shibboleth
openssl-libs.x86_64                     1:1.0.2k-16.el7              @CentOS    
openssl.x86_64                          1:1.0.2k-16.el7              @base      
shibboleth.x86_64                       3.0.3-1.1                    @shibboleth
xmltooling-schemas.x86_64               3.0.3-5.1                    @shibboleth

[root@2eac1a6fe684 tmp]# uname -a
Linux 2eac1a6fe684 4.4.0-135-generic #161-Ubuntu SMP Mon Aug 27 10:45:01 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

e come puoi vedere e' tutto su

[root@2eac1a6fe684 tmp]# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  11696  2552 ?        Ss   20:37   0:00 /bin/sh /usr/sbin/apachectl -DFOREGROUND
root       408  0.0  0.7 888556 29648 ?        Ssl  20:37   0:00 /usr/sbin/shibd
root       418  0.0  0.6 333928 26584 ?        S    20:37   0:00 /usr/sbin/httpd -DFOREGROUND
apache     419  0.0  0.5 558920 21000 ?        Sl   20:37   0:00 /usr/sbin/httpd -DFOREGROUND
apache     420  0.0  0.5 558920 21000 ?        Sl   20:37   0:00 /usr/sbin/httpd -DFOREGROUND
apache     421  0.0  0.5 558920 21000 ?        Sl   20:37   0:00 /usr/sbin/httpd -DFOREGROUND
apache     422  0.0  0.5 558920 21000 ?        Sl   20:37   0:00 /usr/sbin/httpd -DFOREGROUND
apache     424  0.0  0.5 558920 21000 ?        Sl   20:37   0:00 /usr/sbin/httpd -DFOREGROUND
root       443  0.0  0.0  15264  3544 pts/0    Ss   20:37   0:00 bash
root       507  0.0  0.0  55184  3832 pts/0    R+   20:41   0:00 ps aux

State utilizzando un build "clean" dell'immagine oppure avere utilizzato layer esistenti?

Quali sono le modifiche apportate al file z20-auth-proxy.conf.prod?

Riguardano mod_shib o altri aspetti di httpd?

Fabiomad85 commented

Ciao @psmiraglia

effettuando una build clean e lanciando gli stessi comandi che hai lanciato tu ed ecco i risultati:

date
Sat Mar 9 19:54:21 UTC 2019

yum list installed | grep -P "(httpd|shib|ssl)" | sort
httpd-tools.x86_64 2.4.6-88.el7.centos @base httpd.x86_64 2.4.6-88.el7.centos @base libcurl-openssl.x86_64 7.63.0-1.1 @shibboleth liblog4shib2.x86_64 2.0.0-3.1 @shibboleth libsaml10.x86_64 3.0.0-1.2 @shibboleth libxerces-c-3_2.x86_64 3.2.1-1.1 @shibboleth libxml-security-c20.x86_64 2.0.2-3.1 @shibboleth libxmltooling8.x86_64 3.0.3-5.1 @shibboleth mod_ssl.x86_64 1:2.4.6-88.el7.centos @base opensaml-schemas.x86_64 3.0.0-1.2 @shibboleth openssl-libs.x86_64 1:1.0.2k-16.el7 @base openssl.x86_64 1:1.0.2k-16.el7 @base shibboleth.x86_64 3.0.3-1.1 @shibboleth xmltooling-schemas.x86_64 3.0.3-5.1 @shibboleth

uname -a
Linux 4ee11e32098f 4.4.0-128-generic #154-Ubuntu SMP Fri May 25 14:15:18 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.3 0.0 11696 2708 ? Ss 19:54 0:00 /bin/bash /usr/local/bin/docker-bootstrap.sh root 113 0.0 0.0 51752 3436 ? R 19:54 0:00 ps aux

Le personalizzazioni che sono state fatte nel z20-auth-proxy.conf.prod sono relative all'aggiunta di un percorso parametrico a cui passare gli header shibboleth.

L'altra personalizzazione che è stata fatta è iniettare gli ACS in fase di creazione del metadata XML da una chiamata GET ad un endopoint esterno.

Tali personalizzazioni con la versione 0.4.0 funzionavano perfettamente.

psmiraglia commented

L'altra personalizzazione che è stata fatta è iniettare gli ACS in fase di creazione del metadata XML da una chiamata GET ad un endopoint esterno.

Il problema potrebbe essere qui. Come indicato nella sezione How to define AttributeConsumingService elements del README.md, la configurazione relativa agli ACS nel metadata viene generata utilizzando delle envvar specifiche (ACS_INDEXES, ACN_<N>_LABEL, ACN_<N>_ATTRS).

spid-shibboleth-proxy-docker/usr/local/bin/docker-bootstrap.sh

Lines 144 to 168 in 1be15b5

pushd /opt/shibboleth-sp/metadata
cat /dev/null > acs.xml
for idx in $(echo ${ACS_INDEXES} | tr ';' ' '); do
_label="ACS_${idx}_LABEL"
_attrs="ACS_${idx}_ATTRS"
cat >> acs.xml <<EOF
<md:AttributeConsumingService index="${idx}">
<md:ServiceName xml:lang="it">${!_label}</md:ServiceName>
EOF
for attr in $(echo ${!_attrs} | tr ';' ' '); do
echo " <md:RequestedAttribute Name=\"${attr}\"/>" >> acs.xml
done
cat >> acs.xml <<EOF
</md:AttributeConsumingService>
EOF
done
sed \
-e "s/Shibboleth.sso/iam/g" \
-f /opt/spid-metadata/sed.rules ${TMP_METADATA_1} > ${TMP_METADATA_2}
rm -f acs.xml
popd

Queste inoltre, vengono usate per definire le regole di validazione dell'handler di tipo AttributeChecker

spid-shibboleth-proxy-docker/usr/local/bin/docker-bootstrap.sh

Lines 205 to 240 in 1be15b5

# define attribute checker rules
ATTR_CHECK="/tmp/attr-check.xml"
cat /dev/null > ${ATTR_CHECK}
echo " <OR>" >> ${ATTR_CHECK}
for idx in $(echo ${ACS_INDEXES} | tr ';' ' '); do
_label="ACS_${idx}_LABEL"
_attrs="ACS_${idx}_ATTRS"
cat >> ${ATTR_CHECK} <<EOF
<!-- Check AttributeConsumingService with index ${idx} -->
<AND>
<AND>
EOF
# required attributes
for attr in $(echo ${!_attrs} | tr ';' ' '); do
echo " <Rule require=\"$(echo ${attr} | tr [:lower:] [:upper:])\"/>" >> ${ATTR_CHECK}
done
cat >> ${ATTR_CHECK} <<EOF
</AND>
<AND>
EOF
# other attributes
for attr in ${ATTRIBUTES[*]}; do
if ! echo ${!_attrs} | tr [:lower:] [:upper:] | grep -w -q "${attr}"; then
echo " <NOT><Rule require=\"$(echo ${attr} | tr [:lower:] [:upper:])\"/></NOT>" >> ${ATTR_CHECK}
fi
done
cat >> ${ATTR_CHECK} <<EOF
</AND>
</AND>
EOF
done
echo " </OR>" >> ${ATTR_CHECK}

e i vari elementi <SessionInitiator>

spid-shibboleth-proxy-docker/usr/local/bin/docker-bootstrap.sh

Lines 242 to 270 in 1be15b5

# define session initiator(s)
SESSION_INITIATOR="/tmp/session-initiator.xml"
cat /dev/null > ${SESSION_INITIATOR}
for idx in $(echo ${ACS_INDEXES} | tr ';' ' '); do
cat >> ${SESSION_INITIATOR} <<EOF
<!-- SessionInitiator for AttributeConsumingService ${idx} -->
<SessionInitiator type="SAML2"
Location="/Login${idx}"
isDefault="true"
entityID="%ENTITY_ID%"
outgoingBinding="urn:oasis:names:tc:SAML:profiles:SSO:request-init"
isPassive="false"
signing="true">
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Version="2.0" ID="placeholder${idx}.example.com" IssueInstant="1970-01-01T00:00:00Z"
AttributeConsumingServiceIndex="${idx}" ForceAuthn="true">
<saml:Issuer
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity"
NameQualifier="%ENTITY_ID%">
%ENTITY_ID%
</saml:Issuer>
<samlp:NameIDPolicy
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
/>
</samlp:AuthnRequest>
</SessionInitiator>
EOF
done

Se voi acquisite il file acs.xml (o chi per lui) da un vostro endpoint e non definite le envvar di cui sopra, lo script di bootstrap genererà un file di configurazione di Shibboleth (shibboleth2.xml) errato.

La cosa che mi sento di suggerire è quella di importare dal vostro endpoint un file che contiene la definizione delle varie envvar e il resto farlo fare allo script di bootstrap.

Tali personalizzazioni con la versione 0.4.0 funzionavano perfettamente.

Questa immagine docker è versionata seguendo lo schema SemVer e il passaggio dal branch 0.x a 1.x rappresenta un "breaking change", ovvero non è garantita la retro compatibilità.

Fabiomad85 commented

Ciao @psmiraglia

ok, per cercare di riportare tutto ad una situazione di funzionamento, ho rimosso la mia personalizzazione sul metadata ed utilizzo le variabili come indicato nel readme. Senza però avere il risultato desiderato.

nel far partire il container ho aggiunto al comando shib il flag "-t"

#
# run shibd
#
/usr/sbin/shibd -t

il risultato è questo: ( era lo stesso anche con la mia personalizzazione)

2019-03-11T14:10:12.310234714Z overall configuration is loadable, check console or log for non-fatal problems
2019-03-11T14:10:12.316410649Z 2019-03-11 14:10:12 WARN Shibboleth.AttributeExtractor.XML : attribute mappings are reloadable; be sure to restart web server when adding new attribute IDs

allora sempre per finalità di debug ho salvato i file:

#DEBUG
cp -rf $ATTR_CHECK /home/site/wwwroot/metadata/attr-check.xml
cp -rf $SESSION_INITIATOR /home/site/wwwroot/metadata/session-initiator.xml
cp -rf /etc/shibboleth/shibboleth2.xml /home/site/wwwroot/metadata/shibboleth2.xml

# cleanup
rm -f ${ATTR_CHECK} ${SESSION_INITIATOR}

nel aprirli ho notato che sembrano tutti in ordine, però nel file session-initiator.xml
aprendolo con firefox ho notato questo errore

XML Parsing Error: junk after document element
Location: file:///tmp/fz3temp-1/session-initiator.xml
Line Number 24, Column 1:<SessionInitiator type="SAML2"
^

se vuoi posso inviarti i file xml di configurazione che vengono generati, ma essendo dati sensibili, non vorrei postarli qui pubblicamente. Dove posso inviarteli?

Grazie

psmiraglia commented

se vuoi posso inviarti i file xml di configurazione che vengono generati, ma essendo dati sensibili, non vorrei postarli qui pubblicamente. Dove posso inviarteli?

Manda un mail alla mia attenzione a spid.tech@agid.gov.it per prendere contatto. Li poi ci organizziamo per lo scambio delle informazioni.

Fabiomad85 commented

Grazie @psmiraglia , abbiamo provveduto ad inviare il messaggio all'email indicata con ulteriori dati e file diagnostici.

Grazie
Fabiano

Fabiomad85 commented

Ciao @psmiraglia

per caso hai avuto modo di dare un'occhiata ai file che ti ho inviato ieri?
Grazie molte

psmiraglia commented

Ciao @Fabiomad85, purtoppo dai file inviati non si capisce molto. Quello che mi sento di suggerire è di partire da una condizione "vanilla" e funzionante" (es. lo scenario che trovate in /example) e pian piano aggiungere le varie personalizzazioni (preferibilmente una alla volta). In questo modo potete identificare esattamente dove è che ri rompe il meccanismo.

Fabiomad85 commented

Ciao @psmiraglia

ho fatto quanto suggerito, partendo da una zero. Ora Apache parte senza andare in segmentation fault. Unica cosa è che ricevo dei 404 nel url /iam/*

Se lo metto in modalità development tutto risponde 404 tranne il metadata.

Non l'ho detto prima, ma questo container si trova dietro un terminatore SSL e quindi le chiamate arrivano tutte sulla porta 80

Grazie

psmiraglia commented

ho fatto quanto suggerito, partendo da una zero. Ora Apache parte senza andare in segmentation fault. Unica cosa è che ricevo dei 404 nel url /iam/*

Ma shibd parte correttamente? La gestione degli URL /iam/* avviene nelle seguenti direttive

spid-shibboleth-proxy-docker/etc/httpd/conf.d/z20-auth-proxy.conf.prod

Lines 28 to 31 in 1be15b5

<LocationMatch "^/(?!(error|iam|metadata))">
ProxyPass ${X_TARGET_BACKEND}
ProxyPassReverse ${X_TARGET_BACKEND}
</LocationMatch>

che si traducono in "per tutti i path che non e' /iam*, /error* e /metadata* fai ProxyPass verso il backend". Riguardo i path /iam (vedi attributo handlerURL), questi esistono solo se shibd e' partito ed il modulo mod_shib e' stato caricato correttamente in Apache.

spid-shibboleth-proxy-docker/etc/shibboleth/shibboleth2.xml.tpl

Lines 30 to 31 in 1be15b5

<Sessions lifetime="1800" timeout="3600" relayState="ss:mem" handlerURL="/iam"
checkAddress="false" handlerSSL="true" cookieProps="https">

Se lo metto in modalità development tutto risponde 404 tranne il metadata.

La differenza fra dev e prod per quanto riguarda Apache sta' nella lista di path da escludere dalla procedura di ProxyPass

spid-shibboleth-proxy-docker/etc/httpd/conf.d/z20-auth-proxy.conf.dev

Lines 38 to 41 in 1be15b5

<LocationMatch "^/(?!(access|error|iam|metadata|whoami))">
ProxyPass ${X_TARGET_BACKEND}
ProxyPassReverse ${X_TARGET_BACKEND}
</LocationMatch>

Non l'ho detto prima, ma questo container si trova dietro un terminatore SSL e quindi le chiamate arrivano tutte sulla porta 80

Dettaglio non da poco. Citando dalla documentazione

handlerSSL(boolean) (defaults to true)
When true, only web requests over SSL/TLS will be processed by handlers. Other requests may be blocked, or possibly ignored (and usually result in a 404 error) depending on the web server, but will never be processed. This is useful for sites that want to protect SAML protocol traffic but leave actual content unencrypted.

e considerando la configurazione

spid-shibboleth-proxy-docker/etc/shibboleth/shibboleth2.xml.tpl

Lines 30 to 31 in 1be15b5

<Sessions lifetime="1800" timeout="3600" relayState="ss:mem" handlerURL="/iam"
checkAddress="false" handlerSSL="true" cookieProps="https">

il problema ora dovrebbe essere abbastanza chiaro.

Fabiomad85 commented
Fabiomad85 commented
Fabiomad85 commented