Bug 969954 - [REGRESSION] gss_acquire_cred(GSS_C_NO_NAME) fails without kinit
[REGRESSION] gss_acquire_cred(GSS_C_NO_NAME) fails without kinit
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
19
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-03 03:22 EDT by Stefan Becker
Modified: 2013-10-19 14:15 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-04 04:16:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stefan Becker 2013-06-03 03:22:48 EDT
Description of problem:

I'm the maintainer for pidgin-sipe. I just upgraded from Fedora 18 to Fedora 19 Beta and the following piece of code from pidgin-sipe now fails if "kinit" has not been executed first. 

	/* Acquire default user credentials */
	ret = gss_acquire_cred(&minor,
			       GSS_C_NO_NAME,
			       GSS_C_INDEFINITE,
			       GSS_C_NO_OID_SET,
			       GSS_C_INITIATE,
			       &credentials,
			       NULL,
			       NULL);

pidgin-sipe code relies on gss_acquire_cred() to work and falls back to acquiring a TGT (with provided user name & password) if the next step [gss_init_sec_context()] fails.

Version-Release number of selected component (if applicable):
krb5-libs-1.11.2-10.fc19.x86_64

How reproducible:
Always

Steps to Reproduce:
1. pidgin & pidgin-sipe with account that supports Kerberos authentication
2. DO NOT run kinit (or use kdestroy to remove the existing tickets)
3. go online with the account

Actual results:
(09:50:23) sipe: sip_sec_acquire_cred__krb5: started
(09:50:23) sipe: sip_sec_krb5: GSS-API error in gss_acquire_cred (GSS): Unspecified GSS failure.  Minor code may provide more information
(09:50:23) sipe: sip_sec_krb5: GSS-API error in gss_acquire_cred (Mech): No Kerberos credentials available
(09:50:23) sipe: sip_sec_krb5_acquire_credentials: failed to acquire credentials (ret=851968)

Expected results:
No failure


Additional info:
I've already fixed the missing /run/user/0 directory issue from bug #961235. Without that even kinit wouldn't work at all on my machine.

F18 has krb5 1.10.x so I'm guessing the behaviour has changed.

I'm no krb5 expert. It could be that pidgin-sipe code does it wrong, but this approach for non-kinit use case has always worked until now. If the approach is wrong can an krb5 expert point me to the information where & why this was change for krb5 1.11.x?
Comment 1 Simo Sorce 2013-06-03 16:34:41 EDT
Why do you think this call should succeed if you have no crdentials ?

You are trying to acquire credentials, but you have none, and gss_acquire_cred is failing with an error saying you have no credentials, which is the truth as far as I understand.

In 1.10, gss_acquire_cred often does not immediately try to acquire credentials, but defers the operation to the time when gss_init_sec_context() is executed.

All that said, given you are not passing any specific name or option to gss_acquire_cred() you should probably simply remove the call, and use gss_init_sec_context() directly.

To me this looks a a NOTABUG, unless Nalin spots something I missed.
Comment 2 Stefan Becker 2013-06-04 04:16:52 EDT
I didn't write the original code. As the code flow always worked until now, I never suspected that the gss_acquire_cred() call was pointless. I removed it from pidgin-sipe:

  http://repo.or.cz/w/siplcs.git/commitdiff/d19a69fe6afacf7b9fc756e077c70cb3092d1df3

I verified that this works on krb5 1.8.x, 1.10.x & 1.11.x.

Thanks for pointing out the problem. Closing as NOTABUG
Comment 3 David Woodhouse 2013-10-19 13:43:43 EDT
Wait a minute. What if I have to use gss_acquire_cred() just so that I can use gss_set_neg_mechs() for SPNEGO? Surely I might have good reason to use GSS_C_NO_NAME then? Or how *else* do I set the mechanisms for it to use?
Comment 4 Simo Sorce 2013-10-19 13:49:28 EDT
Yes David, if you have a good reason to use gss_acquire_cred() by all means use it. Just do not expect it to always immediately indicate whether you have valid credntials or not, you always have to go all the way to gss_init_sec_context() to find that out.
This is true now as was before, a user can always call kdestroy when your code is doing a reconnection attempt right between your call to gss_acquire_cred() and gss_init_sec_coontext()
Comment 5 David Woodhouse 2013-10-19 14:15:31 EDT
As long as it doesn't *fail*, for SPNEGO, just because I don't have Kerberos creds.

I might have creds for one of the *other* mechanisms that I expect SPNEGO to fall back to...

Note You need to log in before you can comment on or make changes to this bug.