Bug #1561533 “crash after authentication on centos7 with master” : Bugs : Project Moonshot

Revision history for this message

Sam Hartman (hartmans) wrote on 2016-03-24:

#1

Luke, it may be that one of your Heimdal commits broke MIT. I will try to get to this before leaving Painless next week, else someone on our side will look into this.

Revision history for this message

Luke Howard (lukeh-padl) wrote on 2016-03-24: Re: [Bug 1561533] crash after authentication on centos7 with master

#2

Download full text (4.6 KiB)

I will take a look.

> On 25 Mar 2016, at 12:27 AM, Sam Hartman <email address hidden> wrote:
>
> Luke, it may be that one of your Heimdal commits broke MIT. I will try
> to get to this before leaving Painless next week, else someone on our
> side will look into this.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> Matching subscriptions: Moonshot Drivers
> https://bugs.launchpad.net/bugs/1561533
>
> Title:
> crash after authentication on centos7 with master
>
> Status in Project Moonshot:
> Confirmed
>
> Bug description:
> According to Stefan and Alex, if built with a1264ef then you get a coredump on centos7. Interestingly, the stack trace doesn't
> include any of our code, but instead fails in the krb5 library. However, with 28dcddb things work fine.
> I have not tested this yet; it may well be generic with MIT krb5 and not Centos-specific.
> From Stefan:
>
> Starting program: /usr/sbin/gss-server host@localhost
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> starting...
> 2016-03-24 11:29:03 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
> [New Thread 0x7fffe7896700 (LWP 52402)]
> [New Thread 0x7fffe7095700 (LWP 52403)]
> [New Thread 0x7fffe6894700 (LWP 52404)]
> context flag: GSS_C_MUTUAL_FLAG
> context flag: GSS_C_REPLAY_FLAG
> context flag: GSS_C_SEQUENCE_FLAG
> context flag: GSS_C_CONF_FLAG
> context flag: GSS_C_INTEG_FLAG
> Attribute urn:ietf:params:gss:radius-attribute 79 Authenticated Complete
>
>
> 03070004
>
> Attribute urn:ietf:params:gss:radius-attribute 80 Authenticated
> Complete
>
>
> 5de105afdca56834f6fd86330e95ffd0
>
> Accepted connection: ""
> Received message: "boo"
>
> Program received signal SIGSEGV, Segmentation fault.
> kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0, conf_req_flag=0,
> qop_req=0, conf_state=0x0, iov=0x7fffffffdd90, iov_count=2, toktype=257)
> at k5sealiov.c:284
> 284 if (ctx->terminated || !ctx->established) {
> (gdb) bt full
> #0 kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0,
> conf_req_flag=0, qop_req=0, conf_state=0x0, iov=0x7fffffffdd90,
> iov_count=2, toktype=257) at k5sealiov.c:284
> ctx = <optimized out>
> #1 0x00007ffff7bbd24f in krb5_gss_get_mic_iov (minor_status=<optimized out>,
> context_handle=<optimized out>, qop_req=<optimized out>,
> iov=<optimized out>, iov_count=<optimized out>) at k5sealiov.c:537
> major_status = <optimized out>
> #2 0x00007ffff571be48 in gss_get_mic (minor=<optimized out>,
> ctx=<optimized out>, qop_req=<optimized out>,
> message_buffer=<optimized out>, message_token=0x7fffffffdf50)
> at get_mic.c:104
> major = <optimized out>
> iov = {{type = 1, buffer = {length = 3, value = 0x5555557a8720}}, {
> type = 65548, buffer = {length = 0, value = 0x0}}}
> #3 0x00007ffff7bacce4 in gss_get_mic (
> minor_status=minor_status@entry=0x7fffffffdef8,
> context_handle=0x55555575a080, qop_req=qop_req@entry=0,
> message_buffe...

I will take a look.

> On 25 Mar 2016, at 12:27 AM, Sam Hartman <hartmans@debian.org> wrote:
> 
> Luke, it may be that one of your Heimdal commits broke MIT.  I will try
> to get to this before leaving Painless next week, else someone on our
> side will look into this.
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> Matching subscriptions: Moonshot Drivers
> https://bugs.launchpad.net/bugs/1561533
> 
> Title:
>  crash after authentication on centos7 with master
> 
> Status in Project Moonshot:
>  Confirmed
> 
> Bug description:
>  According to Stefan and Alex, if built with a1264ef then you get a coredump on centos7.  Interestingly, the stack trace doesn't 
>  include any of our code, but instead fails in the krb5 library.  However, with  28dcddb things work fine.
>  I have not tested this yet; it may well be generic with MIT krb5 and not Centos-specific.
>  From Stefan:
> 
>  Starting program: /usr/sbin/gss-server host@localhost
>  [Thread debugging using libthread_db enabled]
>  Using host libthread_db library "/lib64/libthread_db.so.1".
>  starting...
>  2016-03-24 11:29:03 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
>  [New Thread 0x7fffe7896700 (LWP 52402)]
>  [New Thread 0x7fffe7095700 (LWP 52403)]
>  [New Thread 0x7fffe6894700 (LWP 52404)]
>  context flag: GSS_C_MUTUAL_FLAG
>  context flag: GSS_C_REPLAY_FLAG
>  context flag: GSS_C_SEQUENCE_FLAG
>  context flag: GSS_C_CONF_FLAG
>  context flag: GSS_C_INTEG_FLAG
>  Attribute urn:ietf:params:gss:radius-attribute 79 Authenticated Complete
> 
> 
>  03070004
> 
>  Attribute urn:ietf:params:gss:radius-attribute 80 Authenticated
>  Complete
> 
> 
>  5de105afdca56834f6fd86330e95ffd0
> 
>  Accepted connection: ""
>  Received message: "boo"
> 
>  Program received signal SIGSEGV, Segmentation fault.
>  kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0, conf_req_flag=0,
>      qop_req=0, conf_state=0x0, iov=0x7fffffffdd90, iov_count=2, toktype=257)
>      at k5sealiov.c:284
>  284	    if (ctx->terminated || !ctx->established) {
>  (gdb) bt full
>  #0  kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0,
>      conf_req_flag=0, qop_req=0, conf_state=0x0, iov=0x7fffffffdd90,
>      iov_count=2, toktype=257) at k5sealiov.c:284
>          ctx = <optimized out>
>  #1  0x00007ffff7bbd24f in krb5_gss_get_mic_iov (minor_status=<optimized out>,
>      context_handle=<optimized out>, qop_req=<optimized out>,
>      iov=<optimized out>, iov_count=<optimized out>) at k5sealiov.c:537
>          major_status = <optimized out>
>  #2  0x00007ffff571be48 in gss_get_mic (minor=<optimized out>,
>      ctx=<optimized out>, qop_req=<optimized out>,
>      message_buffer=<optimized out>, message_token=0x7fffffffdf50)
>      at get_mic.c:104
>          major = <optimized out>
>          iov = {{type = 1, buffer = {length = 3, value = 0x5555557a8720}}, {
>              type = 65548, buffer = {length = 0, value = 0x0}}}
>  #3  0x00007ffff7bacce4 in gss_get_mic (
>      minor_status=minor_status@entry=0x7fffffffdef8,
>      context_handle=0x55555575a080, qop_req=qop_req@entry=0,
>      message_buffer=message_buffer@entry=0x7fffffffdf40,
>      msg_token=msg_token@entry=0x7fffffffdf50) at g_sign.c:101
>          status = 0
>          ctx = 0x55555575a080
>          mech = 0x5555557a1ff0
>  #4  0x000055555555662a in sign_server (s=s@entry=8,
>      server_creds=<optimized out>, export=export@entry=0) at gss-server.c:519
>          client_name = {length = 0, value = 0x5555557acbc0}
>          recv_buf = {length = 63, value = 0x0}
>          unwrap_buf = {length = 3, value = 0x5555557a8720}
>          mic_buf = {length = 0, value = 0x0}
>          msg_buf = 0x7fffffffdf40
>          send_buf = <optimized out>
>          context = 0x55555575a080
>          maj_stat = <optimized out>
>          min_stat = 0
>          i = <optimized out>
>          conf_state = 1
>          ret_flags = 382
>          cp = <optimized out>
>          token_flags = 228
>          send_flags = <optimized out>
>  #5  0x0000555555555bea in worker_bee (param=0x55555575a060) at gss-server.c:640
>          work = 0x55555575a060
>  #6  main (argc=<optimized out>, argv=<optimized out>) at gss-server.c:779
>          work = 0x55555575a060
>          service_name = <optimized out>
>          server_creds = 0x55555575c460
>          min_stat = 1
>          port = <optimized out>
>          once = 0
>          do_inetd = 0
>          export = 0
>  (gdb)
>  -- ends --
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/moonshot/+bug/1561533/+subscriptions

--
www.lukehoward.com
soundcloud.com/lukehoward

Revision history for this message

Luke Howard (lukeh-padl) wrote on 2016-03-24:

#3

Download full text (4.8 KiB)

Although, interestingly gss_get_mic_iov was actually added for MIT compat (not Heimdal). If I can’t reproduce, a stack trace without optimisation would be good.

> On 25 Mar 2016, at 12:27 AM, Sam Hartman <email address hidden> wrote:
>
> Luke, it may be that one of your Heimdal commits broke MIT. I will try
> to get to this before leaving Painless next week, else someone on our
> side will look into this.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> Matching subscriptions: Moonshot Drivers
> https://bugs.launchpad.net/bugs/1561533
>
> Title:
> crash after authentication on centos7 with master
>
> Status in Project Moonshot:
> Confirmed
>
> Bug description:
> According to Stefan and Alex, if built with a1264ef then you get a coredump on centos7. Interestingly, the stack trace doesn't
> include any of our code, but instead fails in the krb5 library. However, with 28dcddb things work fine.
> I have not tested this yet; it may well be generic with MIT krb5 and not Centos-specific.
> From Stefan:
>
> Starting program: /usr/sbin/gss-server host@localhost
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> starting...
> 2016-03-24 11:29:03 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
> [New Thread 0x7fffe7896700 (LWP 52402)]
> [New Thread 0x7fffe7095700 (LWP 52403)]
> [New Thread 0x7fffe6894700 (LWP 52404)]
> context flag: GSS_C_MUTUAL_FLAG
> context flag: GSS_C_REPLAY_FLAG
> context flag: GSS_C_SEQUENCE_FLAG
> context flag: GSS_C_CONF_FLAG
> context flag: GSS_C_INTEG_FLAG
> Attribute urn:ietf:params:gss:radius-attribute 79 Authenticated Complete
>
>
> 03070004
>
> Attribute urn:ietf:params:gss:radius-attribute 80 Authenticated
> Complete
>
>
> 5de105afdca56834f6fd86330e95ffd0
>
> Accepted connection: ""
> Received message: "boo"
>
> Program received signal SIGSEGV, Segmentation fault.
> kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0, conf_req_flag=0,
> qop_req=0, conf_state=0x0, iov=0x7fffffffdd90, iov_count=2, toktype=257)
> at k5sealiov.c:284
> 284 if (ctx->terminated || !ctx->established) {
> (gdb) bt full
> #0 kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0,
> conf_req_flag=0, qop_req=0, conf_state=0x0, iov=0x7fffffffdd90,
> iov_count=2, toktype=257) at k5sealiov.c:284
> ctx = <optimized out>
> #1 0x00007ffff7bbd24f in krb5_gss_get_mic_iov (minor_status=<optimized out>,
> context_handle=<optimized out>, qop_req=<optimized out>,
> iov=<optimized out>, iov_count=<optimized out>) at k5sealiov.c:537
> major_status = <optimized out>
> #2 0x00007ffff571be48 in gss_get_mic (minor=<optimized out>,
> ctx=<optimized out>, qop_req=<optimized out>,
> message_buffer=<optimized out>, message_token=0x7fffffffdf50)
> at get_mic.c:104
> major = <optimized out>
> iov = {{type = 1, buffer = {length = 3, value = 0x5555557a8720}}, {
> type = 65548, buffer = {length = 0, value = 0x0}}}
> #3 0x00007ffff7bacce4 in gss_get_mic...

Although, interestingly gss_get_mic_iov was actually added for MIT compat (not Heimdal). If I can’t reproduce, a stack trace without optimisation would be good.

> On 25 Mar 2016, at 12:27 AM, Sam Hartman <hartmans@debian.org> wrote:
> 
> Luke, it may be that one of your Heimdal commits broke MIT.  I will try
> to get to this before leaving Painless next week, else someone on our
> side will look into this.
> 
> -- 
> You received this bug notification because you are subscribed to the bug
> report.
> Matching subscriptions: Moonshot Drivers
> https://bugs.launchpad.net/bugs/1561533
> 
> Title:
>  crash after authentication on centos7 with master
> 
> Status in Project Moonshot:
>  Confirmed
> 
> Bug description:
>  According to Stefan and Alex, if built with a1264ef then you get a coredump on centos7.  Interestingly, the stack trace doesn't 
>  include any of our code, but instead fails in the krb5 library.  However, with  28dcddb things work fine.
>  I have not tested this yet; it may well be generic with MIT krb5 and not Centos-specific.
>  From Stefan:
> 
>  Starting program: /usr/sbin/gss-server host@localhost
>  [Thread debugging using libthread_db enabled]
>  Using host libthread_db library "/lib64/libthread_db.so.1".
>  starting...
>  2016-03-24 11:29:03 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
>  [New Thread 0x7fffe7896700 (LWP 52402)]
>  [New Thread 0x7fffe7095700 (LWP 52403)]
>  [New Thread 0x7fffe6894700 (LWP 52404)]
>  context flag: GSS_C_MUTUAL_FLAG
>  context flag: GSS_C_REPLAY_FLAG
>  context flag: GSS_C_SEQUENCE_FLAG
>  context flag: GSS_C_CONF_FLAG
>  context flag: GSS_C_INTEG_FLAG
>  Attribute urn:ietf:params:gss:radius-attribute 79 Authenticated Complete
> 
> 
>  03070004
> 
>  Attribute urn:ietf:params:gss:radius-attribute 80 Authenticated
>  Complete
> 
> 
>  5de105afdca56834f6fd86330e95ffd0
> 
>  Accepted connection: ""
>  Received message: "boo"
> 
>  Program received signal SIGSEGV, Segmentation fault.
>  kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0, conf_req_flag=0,
>      qop_req=0, conf_state=0x0, iov=0x7fffffffdd90, iov_count=2, toktype=257)
>      at k5sealiov.c:284
>  284	    if (ctx->terminated || !ctx->established) {
>  (gdb) bt full
>  #0  kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0,
>      conf_req_flag=0, qop_req=0, conf_state=0x0, iov=0x7fffffffdd90,
>      iov_count=2, toktype=257) at k5sealiov.c:284
>          ctx = <optimized out>
>  #1  0x00007ffff7bbd24f in krb5_gss_get_mic_iov (minor_status=<optimized out>,
>      context_handle=<optimized out>, qop_req=<optimized out>,
>      iov=<optimized out>, iov_count=<optimized out>) at k5sealiov.c:537
>          major_status = <optimized out>
>  #2  0x00007ffff571be48 in gss_get_mic (minor=<optimized out>,
>      ctx=<optimized out>, qop_req=<optimized out>,
>      message_buffer=<optimized out>, message_token=0x7fffffffdf50)
>      at get_mic.c:104
>          major = <optimized out>
>          iov = {{type = 1, buffer = {length = 3, value = 0x5555557a8720}}, {
>              type = 65548, buffer = {length = 0, value = 0x0}}}
>  #3  0x00007ffff7bacce4 in gss_get_mic (
>      minor_status=minor_status@entry=0x7fffffffdef8,
>      context_handle=0x55555575a080, qop_req=qop_req@entry=0,
>      message_buffer=message_buffer@entry=0x7fffffffdf40,
>      msg_token=msg_token@entry=0x7fffffffdf50) at g_sign.c:101
>          status = 0
>          ctx = 0x55555575a080
>          mech = 0x5555557a1ff0
>  #4  0x000055555555662a in sign_server (s=s@entry=8,
>      server_creds=<optimized out>, export=export@entry=0) at gss-server.c:519
>          client_name = {length = 0, value = 0x5555557acbc0}
>          recv_buf = {length = 63, value = 0x0}
>          unwrap_buf = {length = 3, value = 0x5555557a8720}
>          mic_buf = {length = 0, value = 0x0}
>          msg_buf = 0x7fffffffdf40
>          send_buf = <optimized out>
>          context = 0x55555575a080
>          maj_stat = <optimized out>
>          min_stat = 0
>          i = <optimized out>
>          conf_state = 1
>          ret_flags = 382
>          cp = <optimized out>
>          token_flags = 228
>          send_flags = <optimized out>
>  #5  0x0000555555555bea in worker_bee (param=0x55555575a060) at gss-server.c:640
>          work = 0x55555575a060
>  #6  main (argc=<optimized out>, argv=<optimized out>) at gss-server.c:779
>          work = 0x55555575a060
>          service_name = <optimized out>
>          server_creds = 0x55555575c460
>          min_stat = 1
>          port = <optimized out>
>          once = 0
>          do_inetd = 0
>          export = 0
>  (gdb)
>  -- ends --
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/moonshot/+bug/1561533/+subscriptions

--
www.lukehoward.com
soundcloud.com/lukehoward

Revision history for this message

Luke Howard (lukeh-padl) wrote on 2016-03-24: Re: [Bug 1561533] [NEW] crash after authentication on centos7 with master

#4

Download full text (8.5 KiB)

If it’s failing inside libkrb5 my (naive) intuition is that it might be a symbol issue, i.e. somehow we’re accidentally calling into MIT’s krb5 mech.

> On 25 Mar 2016, at 12:24 AM, Sam Hartman <email address hidden> wrote:
>
> Public bug reported:
>
> According to Stefan and Alex, if built with a1264ef then you get a coredump on centos7. Interestingly, the stack trace doesn't
> include any of our code, but instead fails in the krb5 library. However, with 28dcddb things work fine.
> I have not tested this yet; it may well be generic with MIT krb5 and not Centos-specific.
>> From Stefan:
>
> Starting program: /usr/sbin/gss-server host@localhost
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> starting...
> 2016-03-24 11:29:03 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
> [New Thread 0x7fffe7896700 (LWP 52402)]
> [New Thread 0x7fffe7095700 (LWP 52403)]
> [New Thread 0x7fffe6894700 (LWP 52404)]
> context flag: GSS_C_MUTUAL_FLAG
> context flag: GSS_C_REPLAY_FLAG
> context flag: GSS_C_SEQUENCE_FLAG
> context flag: GSS_C_CONF_FLAG
> context flag: GSS_C_INTEG_FLAG
> Attribute urn:ietf:params:gss:radius-attribute 79 Authenticated Complete
>
>
> 03070004
>
> Attribute urn:ietf:params:gss:radius-attribute 80 Authenticated Complete
>
>
> 5de105afdca56834f6fd86330e95ffd0
>
> Accepted connection: ""
> Received message: "boo"
>
> Program received signal SIGSEGV, Segmentation fault.
> kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0, conf_req_flag=0,
> qop_req=0, conf_state=0x0, iov=0x7fffffffdd90, iov_count=2, toktype=257)
> at k5sealiov.c:284
> 284 if (ctx->terminated || !ctx->established) {
> (gdb) bt full
> #0 kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0,
> conf_req_flag=0, qop_req=0, conf_state=0x0, iov=0x7fffffffdd90,
> iov_count=2, toktype=257) at k5sealiov.c:284
> ctx = <optimized out>
> #1 0x00007ffff7bbd24f in krb5_gss_get_mic_iov (minor_status=<optimized out>,
> context_handle=<optimized out>, qop_req=<optimized out>,
> iov=<optimized out>, iov_count=<optimized out>) at k5sealiov.c:537
> major_status = <optimized out>
> #2 0x00007ffff571be48 in gss_get_mic (minor=<optimized out>,
> ctx=<optimized out>, qop_req=<optimized out>,
> message_buffer=<optimized out>, message_token=0x7fffffffdf50)
> at get_mic.c:104
> major = <optimized out>
> iov = {{type = 1, buffer = {length = 3, value = 0x5555557a8720}}, {
> type = 65548, buffer = {length = 0, value = 0x0}}}
> #3 0x00007ffff7bacce4 in gss_get_mic (
> minor_status=minor_status@entry=0x7fffffffdef8,
> context_handle=0x55555575a080, qop_req=qop_req@entry=0,
> message_buffer=message_buffer@entry=0x7fffffffdf40,
> msg_token=msg_token@entry=0x7fffffffdf50) at g_sign.c:101
> status = 0
> ctx = 0x55555575a080
> mech = 0x5555557a1ff0
> #4 0x000055555555662a in sign_server (s=s@entry=8,
> server_creds=<optimized out>, export=export@entry=0) at gss-server.c:519
> client_name = {length = 0, value = 0x5555557acbc0}
> recv_buf = {l...

If it’s failing inside libkrb5 my (naive) intuition is that it might be a symbol issue, i.e. somehow we’re accidentally calling into MIT’s krb5 mech.

> On 25 Mar 2016, at 12:24 AM, Sam Hartman <hartmans@debian.org> wrote:
> 
> Public bug reported:
> 
> According to Stefan and Alex, if built with a1264ef then you get a coredump on centos7.  Interestingly, the stack trace doesn't 
> include any of our code, but instead fails in the krb5 library.  However, with  28dcddb things work fine.
> I have not tested this yet; it may well be generic with MIT krb5 and not Centos-specific.
>> From Stefan:
> 
> Starting program: /usr/sbin/gss-server host@localhost
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> starting...
> 2016-03-24 11:29:03 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
> [New Thread 0x7fffe7896700 (LWP 52402)]
> [New Thread 0x7fffe7095700 (LWP 52403)]
> [New Thread 0x7fffe6894700 (LWP 52404)]
> context flag: GSS_C_MUTUAL_FLAG
> context flag: GSS_C_REPLAY_FLAG
> context flag: GSS_C_SEQUENCE_FLAG
> context flag: GSS_C_CONF_FLAG
> context flag: GSS_C_INTEG_FLAG
> Attribute urn:ietf:params:gss:radius-attribute 79 Authenticated Complete
> 
> 
> 03070004
> 
> Attribute urn:ietf:params:gss:radius-attribute 80 Authenticated Complete
> 
> 
> 5de105afdca56834f6fd86330e95ffd0
> 
> Accepted connection: ""
> Received message: "boo"
> 
> Program received signal SIGSEGV, Segmentation fault.
> kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0, conf_req_flag=0,
>    qop_req=0, conf_state=0x0, iov=0x7fffffffdd90, iov_count=2, toktype=257)
>    at k5sealiov.c:284
> 284	    if (ctx->terminated || !ctx->established) {
> (gdb) bt full
> #0  kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0,
>    conf_req_flag=0, qop_req=0, conf_state=0x0, iov=0x7fffffffdd90,
>    iov_count=2, toktype=257) at k5sealiov.c:284
>        ctx = <optimized out>
> #1  0x00007ffff7bbd24f in krb5_gss_get_mic_iov (minor_status=<optimized out>,
>    context_handle=<optimized out>, qop_req=<optimized out>,
>    iov=<optimized out>, iov_count=<optimized out>) at k5sealiov.c:537
>        major_status = <optimized out>
> #2  0x00007ffff571be48 in gss_get_mic (minor=<optimized out>,
>    ctx=<optimized out>, qop_req=<optimized out>,
>    message_buffer=<optimized out>, message_token=0x7fffffffdf50)
>    at get_mic.c:104
>        major = <optimized out>
>        iov = {{type = 1, buffer = {length = 3, value = 0x5555557a8720}}, {
>            type = 65548, buffer = {length = 0, value = 0x0}}}
> #3  0x00007ffff7bacce4 in gss_get_mic (
>    minor_status=minor_status@entry=0x7fffffffdef8,
>    context_handle=0x55555575a080, qop_req=qop_req@entry=0,
>    message_buffer=message_buffer@entry=0x7fffffffdf40,
>    msg_token=msg_token@entry=0x7fffffffdf50) at g_sign.c:101
>        status = 0
>        ctx = 0x55555575a080
>        mech = 0x5555557a1ff0
> #4  0x000055555555662a in sign_server (s=s@entry=8,
>    server_creds=<optimized out>, export=export@entry=0) at gss-server.c:519
>        client_name = {length = 0, value = 0x5555557acbc0}
>        recv_buf = {length = 63, value = 0x0}
>        unwrap_buf = {length = 3, value = 0x5555557a8720}
>        mic_buf = {length = 0, value = 0x0}
>        msg_buf = 0x7fffffffdf40
>        send_buf = <optimized out>
>        context = 0x55555575a080
>        maj_stat = <optimized out>
>        min_stat = 0
>        i = <optimized out>
>        conf_state = 1
>        ret_flags = 382
>        cp = <optimized out>
>        token_flags = 228
>        send_flags = <optimized out>
> #5  0x0000555555555bea in worker_bee (param=0x55555575a060) at gss-server.c:640
>        work = 0x55555575a060
> #6  main (argc=<optimized out>, argv=<optimized out>) at gss-server.c:779
>        work = 0x55555575a060
>        service_name = <optimized out>
>        server_creds = 0x55555575c460
>        min_stat = 1
>        port = <optimized out>
>        once = 0
>        do_inetd = 0
>        export = 0
> (gdb)
> -- ends --
> 
> ** Affects: moonshot
>     Importance: High
>         Status: Confirmed
> 
> -- 
> You received this bug notification because you are a member of Moonshot
> Drivers, which is subscribed to Project Moonshot.
> Matching subscriptions: Moonshot Drivers
> https://bugs.launchpad.net/bugs/1561533
> 
> Title:
>  crash after authentication on centos7 with master
> 
> Status in Project Moonshot:
>  Confirmed
> 
> Bug description:
>  According to Stefan and Alex, if built with a1264ef then you get a coredump on centos7.  Interestingly, the stack trace doesn't 
>  include any of our code, but instead fails in the krb5 library.  However, with  28dcddb things work fine.
>  I have not tested this yet; it may well be generic with MIT krb5 and not Centos-specific.
>  From Stefan:
> 
>  Starting program: /usr/sbin/gss-server host@localhost
>  [Thread debugging using libthread_db enabled]
>  Using host libthread_db library "/lib64/libthread_db.so.1".
>  starting...
>  2016-03-24 11:29:03 CRIT XMLTooling.Config : libcurl lacks OpenSSL-specific options, this will greatly limit functionality
>  [New Thread 0x7fffe7896700 (LWP 52402)]
>  [New Thread 0x7fffe7095700 (LWP 52403)]
>  [New Thread 0x7fffe6894700 (LWP 52404)]
>  context flag: GSS_C_MUTUAL_FLAG
>  context flag: GSS_C_REPLAY_FLAG
>  context flag: GSS_C_SEQUENCE_FLAG
>  context flag: GSS_C_CONF_FLAG
>  context flag: GSS_C_INTEG_FLAG
>  Attribute urn:ietf:params:gss:radius-attribute 79 Authenticated Complete
> 
> 
>  03070004
> 
>  Attribute urn:ietf:params:gss:radius-attribute 80 Authenticated
>  Complete
> 
> 
>  5de105afdca56834f6fd86330e95ffd0
> 
>  Accepted connection: ""
>  Received message: "boo"
> 
>  Program received signal SIGSEGV, Segmentation fault.
>  kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0, conf_req_flag=0,
>      qop_req=0, conf_state=0x0, iov=0x7fffffffdd90, iov_count=2, toktype=257)
>      at k5sealiov.c:284
>  284	    if (ctx->terminated || !ctx->established) {
>  (gdb) bt full
>  #0  kg_seal_iov (minor_status=0x7fffffffdef8, context_handle=0x0,
>      conf_req_flag=0, qop_req=0, conf_state=0x0, iov=0x7fffffffdd90,
>      iov_count=2, toktype=257) at k5sealiov.c:284
>          ctx = <optimized out>
>  #1  0x00007ffff7bbd24f in krb5_gss_get_mic_iov (minor_status=<optimized out>,
>      context_handle=<optimized out>, qop_req=<optimized out>,
>      iov=<optimized out>, iov_count=<optimized out>) at k5sealiov.c:537
>          major_status = <optimized out>
>  #2  0x00007ffff571be48 in gss_get_mic (minor=<optimized out>,
>      ctx=<optimized out>, qop_req=<optimized out>,
>      message_buffer=<optimized out>, message_token=0x7fffffffdf50)
>      at get_mic.c:104
>          major = <optimized out>
>          iov = {{type = 1, buffer = {length = 3, value = 0x5555557a8720}}, {
>              type = 65548, buffer = {length = 0, value = 0x0}}}
>  #3  0x00007ffff7bacce4 in gss_get_mic (
>      minor_status=minor_status@entry=0x7fffffffdef8,
>      context_handle=0x55555575a080, qop_req=qop_req@entry=0,
>      message_buffer=message_buffer@entry=0x7fffffffdf40,
>      msg_token=msg_token@entry=0x7fffffffdf50) at g_sign.c:101
>          status = 0
>          ctx = 0x55555575a080
>          mech = 0x5555557a1ff0
>  #4  0x000055555555662a in sign_server (s=s@entry=8,
>      server_creds=<optimized out>, export=export@entry=0) at gss-server.c:519
>          client_name = {length = 0, value = 0x5555557acbc0}
>          recv_buf = {length = 63, value = 0x0}
>          unwrap_buf = {length = 3, value = 0x5555557a8720}
>          mic_buf = {length = 0, value = 0x0}
>          msg_buf = 0x7fffffffdf40
>          send_buf = <optimized out>
>          context = 0x55555575a080
>          maj_stat = <optimized out>
>          min_stat = 0
>          i = <optimized out>
>          conf_state = 1
>          ret_flags = 382
>          cp = <optimized out>
>          token_flags = 228
>          send_flags = <optimized out>
>  #5  0x0000555555555bea in worker_bee (param=0x55555575a060) at gss-server.c:640
>          work = 0x55555575a060
>  #6  main (argc=<optimized out>, argv=<optimized out>) at gss-server.c:779
>          work = 0x55555575a060
>          service_name = <optimized out>
>          server_creds = 0x55555575c460
>          min_stat = 1
>          port = <optimized out>
>          once = 0
>          do_inetd = 0
>          export = 0
>  (gdb)
>  -- ends --
> 
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/moonshot/+bug/1561533/+subscriptions

--
www.lukehoward.com
soundcloud.com/lukehoward

Revision history for this message

Luke Howard (lukeh-padl) wrote on 2016-03-25:

#5

I can’t reproduce this with MIT master. Does 45a7e558 in mech_eap fix it?

— Luke

Revision history for this message

Sam Hartman (hartmans) wrote on 2016-03-25:

#6

Stefan, I've assigned to you since Alex doesn't seem to have a launchpad account. Can you coordinate to see if that fixes? I'm not going to have time to deal with this tomorrow on our end.

Changed in moonshot:
assignee:	nobody → Stefan Paetow (stefan-paetow)

Revision history for this message

Stefan Paetow (stefan-paetow) wrote on 2016-04-04:

#7

Have asked Alex to rebuild with that commit. We'll retest and see if that causes a blowup or not. If not, I assume it's fixed. :-)

Revision history for this message

Alejandro Perez (alejandro-perez-mendez) wrote on 2016-04-05:

#8

I do have an account, but associated to my Gmail ID :).
It is still SIGSEGV at the same point :(.

---- This is to verify the commit was correctly applied to the packages

nm /usr/lib/debug/usr/lib64/gss/mech_eap.so.debug | grep mic_iov
0000000000020d40 T gss_get_mic_iov
000000000002eb40 T gss_verify_mic_iov

Revision history for this message

Margaret Cullen (mrw42) wrote on 2017-04-28:

#9

As mentioned above, it would be good to get a stack trace without optimization to determine why this is happening, as Luke was not able to reproduce this. Alejandro, do you still have a set-up where you can reproduce this? If so, could you build without optimization and send a stack trace?

Revision history for this message

Margaret Cullen (mrw42) wrote on 2017-04-28:

#10

Subscribed Alejandro to this bug, so he will see the comments I made above.

Revision history for this message

Alejandro Perez (alejandro-perez-mendez) wrote on 2017-04-28:

#11

Hi Margaret,

I don't have the set up, but IIRC it was easy to get the error.
Is there any particular flag I should be using to avoid optimization? I thought I got it right :)

Rhys Smith (rhys-smith) on 2017-05-15

Changed in moonshot:
assignee:	Stefan Paetow (stefan-paetow) → Margaret Cullen (mrw42)

Revision history for this message

Stefan Paetow (stefan-paetow) wrote on 2017-05-15:

#12

Use CentOS 7 with the latest commit and use gss-server and gss-client to try and invoke this.

Margaret Cullen (mrw42) on 2017-05-15

Changed in moonshot:
assignee:	Margaret Cullen (mrw42) → Dan Breslau (dbreslau)

Revision history for this message

Alejandro Perez (alejandro-perez-mendez) wrote on 2017-05-15:

#13

Hi Margaret,

the SIGSEGV is still there. I have easily reproduced it on a newly created Centos 7 LXC container.
The problem is that I don't see an easy way of getting rid of the <optimized out> variables.
If you can guide me through the process, I'd be more than pleased to help you (I will keep the set up for some weeks now).

Nevertheless, let me describe the steps to simulate this scenario using LXC. Perhaps the problem is on how I'm building and installing the SW:
1. Create a new LXC container: Centos 7 AMD64
2. yum install epel-release wget
3. cd /etc/yum.repos.d
4. wget http://download.opensuse.org/repositories/security://shibboleth/CentOS_7/security:shibboleth.repo
5.yum install nano automake autoconf libtool libconfuse-devel python fakeroot krb5-devel libevent-devel wget git boost-devel libconfuse-devel gcc-c++ bash-completion log4cpp-devel xerces-c-devel openssl-devel libcurl-devel gtk2-devel dbus-devel glib-devel libgee-devel dbus-glib-devel shared-mime-info gnome-keyring-devel libgnome-keyring-devel desktop-file-utils make libxml-security-c-devel gettext-devel libgee06-devel vala libsaml-devel opensaml-schemas opensaml-bin shibboleth-devel shibboleth-resolver-devel
6. git clone --recursive http://www.project-moonshot.org/git/moonshot.git
7. edit source_packages and enable only: libradsec jansson ui moonshot
7. Execute the builder (no additional options).
8. ln -s /usr/local/moonhost/lib/gss /usr/lib64
9. Copy moonshot/mech_eap/mech into /etc/gss/mech.d/moonshot.conf
10. Create a /usr/local/moonshot/etc/radsec.conf file (mine uses UDP instead of RADSEC for convenience, I don't think it's relevant thought).
11. Execute gss-server test@test and try to authenticate using a gss-client. At the end of the authentication process, gss-server MUST fail.

Hope this helps!

Revision history for this message

Margaret Cullen (mrw42) wrote on 2017-05-15:

#14

Assigned to Dan, since he currently has a CentOS 7 build environment available.

Project Moonshot

crash after authentication on centos7 with master

Bug Description

Other bug subscribers

Remote bug watches