pythongssapi / python-gssapi

A Python interface to RFC 2743/2744 (plus common extensions)
ISC License
104 stars 46 forks source link

KRB5_TRACE is set but not creating logs #332

Closed john-tipper closed 12 months ago

john-tipper commented 1 year ago

KRB5_TRACE does not create logs

I am trying to generate debug logs of a Flask app that uses Kerberos authentication by setting the environmental variable KRB5_TRACE=/dev/stdout but no logs are being generated. When I run kinit with that variable set I can see logs generated, so I know that my version of Kerberos does support this trace logging.

Is this by design (perhaps because the library is creating a secure context - I can see in the docs for krb5_init_secure_context() that environmental variables are ignored), or am I doing something wrong or is this a bug?

How do we reproduce?

I am using the Kerberos wrapper function here and the example Flask app here: https://github.com/pythongssapi/python-gssapi/issues/164#issuecomment-509978190

Component versions (python-gssapi, Kerberos, OS / distro, etc.)

python-gssapi 1.8.3 Kerberos 1.20.1 Amazon Linux 2

jborean93 commented 1 year ago

This library works just fine with the env var, it does nothing to configure any of the log settings.

import gssapi

krb5 = gssapi.OID.from_int_seq("1.2.840.113554.1.2.2")
c = gssapi.SecurityContext(
    name=gssapi.Name("host@dc01.domain.test", name_type=gssapi.NameType.hostbased_service),
    mech=krb5,
    usage="initiate",
)
c.step()

For example

$ KRB5_TRACE=/dev/stdout python - <<EOF
import gssapi

krb5 = gssapi.OID.from_int_seq("1.2.840.113554.1.2.2")
c = gssapi.SecurityContext(
    name=gssapi.Name("host@dc01.domain.test", name_type=gssapi.NameType.hostbased_service),
    mech=krb5,
    usage="initiate",
)
c.step()
EOF
[71413] 1698702767.322578: TXT record _kerberos.dc01.domain.test. not found
[71413] 1698702767.322579: TXT record _kerberos.domain.test. not found
[71413] 1698702767.322580: TXT record _kerberos.test. not found
[71413] 1698702767.322581: ccselect module realm chose cache FILE:/tmp/krb5cc_1000 with client principal vagrant-domain@DOMAIN.TEST for server principal host/dc01.domain.test@DOMAIN.TEST
[71413] 1698702767.322582: Getting credentials vagrant-domain@DOMAIN.TEST -> host/dc01.domain.test@ using ccache FILE:/tmp/krb5cc_1000
[71413] 1698702767.322583: Retrieving vagrant-domain@DOMAIN.TEST -> krb5_ccache_conf_data/start_realm@X-CACHECONF: from FILE:/tmp/krb5cc_1000 with result: -1765328243/Matching credential not found (filename: /tmp/krb5cc_1000)
[71413] 1698702767.322584: Retrieving vagrant-domain@DOMAIN.TEST -> host/dc01.domain.test@ from FILE:/tmp/krb5cc_1000 with result: 0/Success
[71413] 1698702767.322585: Creating authenticator for vagrant-domain@DOMAIN.TEST -> host/dc01.domain.test@, seqnum 752672861, subkey aes256-cts/5881, session key aes256-cts/DD5E

I can see in the docs for krb5_init_secure_context() that environmental variables are ignored), or am I doing something wrong or is this a bug?

We don't call any of the krb5 APIs, it's all just the gssapi ones. Internally GSSAPI may be calling whatever it likes but that's not something that we can control here.

If it's not working for you I would verify that /dev/stdout is actually valid in the context where your code is running, the env var is actually set, you are using MIT krb5 (Heimdal doesn't use this env var in public builds).

john-tipper commented 1 year ago

Thanks for the very prompt response, really much appreciated. Is there a way of determining whether I have MIT or Heimdal Kerberos installed please? I'm using the krb5-devel and krb5-libs RPMs from the amzn2-core repo but I don't know what implementation they represent - I'd like to be able to rule out the use of Heimdal as being the cause.

jborean93 commented 1 year ago

You will have MIT krb5 with those package names. In any case krb5-config --version will show Kerberos 5 release ... for MIT and for Heimdal includes Heimdal in the output.

john-tipper commented 12 months ago

You’re right, sorry for the noise. The lack of logs was due to a Kerberos error with an incorrectly created keytab which was taking place before the logs started.