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
|