Bug 1279249
| Summary: | gss_accept_sec_context fails to return an output_token in certain error cases | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Richard Sharpe <realrichardsharpe> | ||||||||
| Component: | krb5 | Assignee: | Robbie Harwood <rharwood> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> | ||||||||
| Severity: | unspecified | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 6.7 | CC: | dpal, jplans, nalin, pkis, realrichardsharpe, rharwood, ssorce | ||||||||
| Target Milestone: | rc | Keywords: | Reopened | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | krb5-1.10.3-54.el6 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2016-05-11 01:01:24 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Richard Sharpe
2015-11-08 20:52:23 UTC
Created attachment 1091426 [details]
A packet capture showing what should be returned
This capture against a Windows server shows that we should see a krb-error in the response.
Created attachment 1091440 [details]
Shows the incorrect response
This shows the incorrect response.
This was with Samba 4.3-pre, but is caused by problems in gss_accept_sec_token which is called by source3/librpc/crypto/gse.c in Samba.
When I installed a more recent version of Kerberos (by painfully building RPMs with krb5-1.13.2) the correct response is returned.
I have filed a related informational bug in the Samba bugzilla here: https://bugzilla.samba.org/show_bug.cgi?id=11592 If the time is such that the ticket is not yet valid or expired, I don't understand why we should return anything else. Kerberos requires that clocks be synchronized to within the clock skew. It will not work otherwise. The way in which krb5 fails here is correct to my understanding. Robbie, GSSAPI is supposed to return an output token with some error messages, reopening to better understand the issue. Richard, I found this commit upstream that I do not think ever landed in 1.10 https://github.com/krb5/krb5/commit/c547bc16f2ab6ee66c076ef944c3fbac8a66f5d4 Would you be able to rebuild 1.10 with this patch and verify if it fixes the issue ? (In reply to Simo Sorce from comment #6) > Robbie, > GSSAPI is supposed to return an output token with some error messages, > reopening to better understand the issue. > > Richard, > I found this commit upstream that I do not think ever landed in 1.10 > https://github.com/krb5/krb5/commit/c547bc16f2ab6ee66c076ef944c3fbac8a66f5d4 > > Would you be able to rebuild 1.10 with this patch and verify if it fixes the > issue ? OK, Give me a couple of days and I will do that. Thanks. OK, from the look of the patch it does fix it, and seems to have been applied to 1.13.x. I will try to apply it today and test, but it might slip a few more days. I was mistaken in one aspect of my claims above. krb5-1.13.2 does not return GSS_C_CONTINUE_NEEDED, it still returns GSS_C_FAILURE, however, it does return a token that we can return to the client in the case of TKT_NYV or TKT_EXPIRED. I have now verified that the patch Simo mentioned works (with minor changes) for krb-1.10.3 with my modified Samba. My changes to Samba convert the status code to GSS_C_CONTINUE_NEEDED when TKT_NYV or TKT_EXPIRED are the minor code. Attached is the patch I applied. I skipped the test program. I have not attached any SPEC file changes. Created attachment 1092447 [details]
A slightly modified patch to implement a partial fix
This patch causes gss_accept_sec_context to return a token in the case of an error with the ticket.
It applies to krb5-1.10.3 and is based on the one Simo mentioned up above.
Richard, thanks a lot. The patch looks good. On the samba side, you shouldn't change the status code do GSS_C_CONTINUE_NEEDED, but rather teach it how to return tokens even when GSS_S_FAILURE is returned. Robbie, we'll have to carefully verify that it has no unintended side effects when backported to 1.10, we should probably ask upstream what they think about this, in case they know of other changes in later versions that will affect how this backport behaves. > On the samba side, you shouldn't change the status code do
> GSS_C_CONTINUE_NEEDED, but rather teach it how to return tokens
> even when GSS_S_FAILURE is returned.
Yes, I was coming to that conclusion.
That is a relatively simple change, I believe.
Simo has checked with upstream and this should be reasonable. My understanding is that for he complete end-to-end test samba has to be modified too. Is that the case? And also, would it be possible to backport the test part too? (In reply to Patrik Kis from comment #15) > My understanding is that for he complete end-to-end test samba has to be > modified too. Is that the case? > > And also, would it be possible to backport the test part too? A fix has already been committed to Samba. It might already be in the latest release. There is no automated test, however. This was simulated by changing the time on the Samba server after tickets have been issued. (In reply to Patrik Kis from comment #15) > And also, would it be possible to backport the test part too? Yes, it is. I have backported the test (and checked its failure.). 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://rhn.redhat.com/errata/RHBA-2016-0945.html |