I do not have s390x hardware.  Could you please give me access to a machine which reproduces this failure if you would like it investigated?

Thanks Branislav.

What's happening here is that httpd doesn't seem to be setting one of our command variables correctly: GssapiPublishErrors, which gets loaded into cfg->enverrs.  (This causes the error strings to not be included in the HTTP response, which breaks the test suite; you can still see them in httpd's error_log.)  cfg->envvars is read-only from the perspective of mod_auth_gssapi; we expect httpd to fill it in.  On x86_64 (and I assume all other architectures, since the test suite passes there), this variable is set correctly, and we behave as expected.

Reproducing can use QE's tests or our upstream tests.  I've been setting `-X` on httpd's launch to make attaching gdb easier, but this doesn't seem to change behavior either way.  Our command table is at src/mod_auth_gssapi.c:1827; the check in question is located in mag_post_error() at src/mod_auth_gssapi.c:118, and for this test comes from mag_basic_auth() at src/mod_auth_gssapi.c:610.

Accordingly, this is reassigned to httpd.

mod_auth_gssapi is using:

    AP_INIT_FLAG("GssapiPublishErrors", ap_set_flag_slot,
                 (void *)APR_OFFSETOF(struct mag_config, enverrs), OR_AUTHCFG,
                 "Publish GSSAPI Errors in Envionment Variables"),

but enverrs is a bool:

    bool enverrs;

ap_set_flag_slot() requires a variable with sizeof(int) whereas it looks like sizeof(bool) is not fixed by C99, only "big enough to store one bit".  On x86_64 sizeof(bool) is sizeof(char) anyway, so it's broken everywhere.

The simplest fix would be to change envvers to type int.

The other use of ap_set_flag_slot in this module:

    AP_INIT_FLAG("GssapiImpersonate", ap_set_flag_slot,
          (void *)APR_OFFSETOF(struct mag_config, s4u2self), OR_AUTHCFG,
               "Do impersonation call (S4U2Self) "
               "based on already authentication username"),

also has the same problem; using either these directives may be splatting over other config fields in nasty ways depending on the struct padding.

Thanks Joe.  Posted fix upstream.

Verified using:
mod_auth_gssapi-1.6.1-6.el8.s390x

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Test
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 01:52:55 ] :: [  BEGIN   ] :: Running upstream test suite :: actually running '/usr/bin/python2 tests/magtests.py --so-dir /usr/lib64/httpd/modules/'
SPNEGO: SUCCESS
SPNEGO Proxy Auth: SUCCESS
SPNEGO No Auth: SUCCESS
SPNEGO Rewrite: SUCCESS
SPNEGO Negotiate Once: SUCCESS
HOSTNAME ACCEPTOR: SUCCESS
BAD ACCEPTOR: SUCCESS
Required Name Attr: SUCCESS
BASIC-AUTH: SUCCESS
BASIC-AUTH Two Users: SUCCESS
BASIC Fail Second User: SUCCESS
BASIC Proxy Auth: SUCCESS
NO Negotiate: SUCCESS
:: [ 01:53:06 ] :: [   PASS   ] :: Running upstream test suite (Expected 0, got 0)
:: [ 01:53:06 ] :: [   PASS   ] :: File '/var/tmp/rlRun_LOG.lFqUvHqs' should contain 'SUCCESS'
:: [ 01:53:06 ] :: [   PASS   ] :: File '/var/tmp/rlRun_LOG.lFqUvHqs' should not contain 'FAILED'
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 11s
::   Assertions: 3 good, 0 bad
::   RESULT: PASS (Test)

As per comment #0
Test {BASIC Fail Second User: } is not failed on latest version.

Based on this marking bz as verified.

Created attachment 1588607 [details]
test console logs

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3324