Hi Frank,
Can you post the raw SAML that the AA releases? Is it a basic <saml:Assertion> that's being returned, or is it wrapped inside an <ecp:Response>? In July last year, Vincent Giersch from Uni Kent had a similar problem and once he pulled the Assertion statement from the ECP response, it all functioned ok. I don't know if this occurs here as well or not.
Stefan
> -----Original Message-----
> From: Frank Tamás [mailto:[log in to unmask]]
> Sent: 08 April 2014 13:37
> To: [log in to unmask]
> Subject: debian moonshot-gss-eap segfault, AttributeQuery
>
> Hello,
>
> I've set up our moonshot-enabled ssh server, but there is a scenario
> where I get 'segmentation fault'. Our shibboleth SP would use the value
> of eduPersonEntitlement attribute to make decision about releasing
> local-login-user attribute to the ssh server. If the entitlement
> attribute comes form the SAML assertion issued by the Radius IdP, it
> works fine, but if shibboleth SP asks an AttributeAuthority about the
> user's entitlement with AttributeQuery, and the answer contains at
> least one value, it crashes with segfault.
>
> I have checked it with gdb:
>
> # gdb /usr/sbin/sshd
> (gdb) set args -D -d -p 3022
> (gdb) run
> ...
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000000000 in ?? ()
>
> (gdb) bt
> #0 0x0000000000000000 in ?? ()
> #1 0x00007ffff4ff5b1b in
> gss_eap_shib_attr_provider::duplicateAttribute (src=<optimized out>) at
> util_shib.cpp:517
> #2 0x00007ffff4ff5fa2 in
> gss_eap_shib_attr_provider::duplicateAttributes (src=...) at
> util_shib.cpp:532
> #3 0x00007ffff4ff6301 in
> gss_eap_shib_attr_provider::initWithExistingContext
> (this=0x55555582c1f0, manager=<optimized out>, ctx=0x5555558e02c0) at
> util_shib.cpp:109
> #4 0x00007ffff4fee6b3 in gss_eap_attr_ctx::initWithExistingContext
> (this=this@entry=0x555555c0f280, manager=0x5555559f1fe0) at
> util_attr.cpp:246
> #5 0x00007ffff4fefdd9 in gssEapDuplicateAttrContext
> (minor=minor@entry=0x7fffffffd82c, in=in@entry=0x555555830c60,
> out=0x55555582a440) at util_attr.cpp:1066
> #6 0x00007ffff4fe76ba in gssEapCanonicalizeName
> (minor=minor@entry=0x7fffffffd82c, input_name=0x555555830c60,
> mech_type=mech_type@entry=0x0,
> dest_name=dest_name@entry=0x7fffffffd968) at util_name.c:681
> #7 0x00007ffff4fe770a in gssEapDuplicateName
> (minor=minor@entry=0x7fffffffd82c, input_name=<optimized out>,
> dest_name=dest_name@entry=0x7fffffffd968) at util_name.c:702
> #8 0x00007ffff4fedc6f in gssEapAcceptSecContext
> (minor=minor@entry=0x55555580a354, ctx=0x55555580db80,
> cred=0x55555580afe0, input_token=0x7fffffffdb20,
> input_chan_bindings=0x0,
> src_name=0x7fffffffd968, mech_type=mech_type@entry=0x7fffffffd978,
> output_token=output_token@entry=0x7fffffffdb40,
> ret_flags=ret_flags@entry=0x7fffffffd95c,
> time_rec=time_rec@entry=0x0,
> delegated_cred_handle=delegated_cred_handle@entry=0x7fffffffd960) at
> accept_sec_context.c:933
> #9 0x00007ffff4fede7b in gss_accept_sec_context (minor=0x55555580a354,
> context_handle=0x55555580da60, cred=<optimized out>,
> input_token=<optimized out>,
> input_chan_bindings=<optimized out>, src_name=<optimized out>,
> mech_type=0x7fffffffd978, output_token=0x7fffffffdb40,
> ret_flags=0x7fffffffd95c, time_rec=0x0,
> delegated_cred_handle=0x7fffffffd960) at accept_sec_context.c:1071
> #10 0x00007ffff6b2c7a8 in gss_accept_sec_context () from
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
> #11 0x0000555555581ed1 in ?? ()
> #12 0x0000555555582d95 in kexgss_server ()
> #13 0x00005555555a3ca5 in kex_input_kexinit ()
> #14 0x00005555555a3257 in ?? ()
> #15 0x000055555556346c in main ()
>
>
> Has anybody seen this bug yet?
>
> cheers,
> --
> Tamas
--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
|