Bug 1034690

Summary:	klist doesn't print the cache location if a KEYRING: cache doesn't exist
Product:	Red Hat Enterprise Linux 7	Reporter:	Karel Volný <kvolny>
Component:	krb5	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Patrik Kis <pkis>
Severity:	low	Docs Contact:
Priority:	low
Version:	7.0	CC:	dpal, pkis
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	Regression
Fixed In Version:	krb5-1.11.3-36.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1572651 (view as bug list)		Environment:
Last Closed:	2014-06-13 09:24:23 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:

Description Karel Volný 2013-11-26 10:56:23 UTC

Description of problem:
In REHL6, klist printed where the credential cache resides.
The new version prints this information only if the cache is not empty.

Version-Release number of selected component (if applicable):
krb5-workstation-1.11.3-34.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1. kdestroy
2. klist

Actual results:
klist: No credentials cache found while retrieving principal name

Expected results:
klist: No credentials cache found (ticket cache DIR::/run/user/0/krb5cc/tkt)

Additional info:
the expected result is taken from Fedora; on RHEL6 machine, I got:

klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

Comment 1 Dmitri Pal 2013-11-26 19:10:09 UTC

This is a wrong expectation. Cache is now in kernel keyring and not in a file or directory. It is OK that it does not say anything. If it is inconsistent with the case when there are tickets then there is a problem but that would be a different bug.
I am inclined to close this as works as expected.

Comment 2 Dmitri Pal 2013-11-26 19:22:00 UTC

This is a low priority. Giving ack. We will fix if we have time.

Comment 3 Nalin Dahyabhai 2013-11-26 19:23:18 UTC

If it's a KEYRING: cache, we don't include the cache name.  For FILE: and DIR:, we do.

Comment 4 Karel Volný 2013-11-29 12:14:05 UTC

(In reply to Dmitri Pal from comment #1)
> This is a wrong expectation.

well, I'd appreciate a bit more verbose explanation what is wrong with expecting consistent behaviour, from the UX design point of view ...

> Cache is now in kernel keyring and not in a file or directory.

so, if we have

klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)

or

klist: No credentials cache found (ticket cache DIR::/run/user/0/krb5cc/tkt)

why can't we have something like

klist: No credentials cache found (ticket cache KEYRING:persistent:1001:1001)

?

> If it is inconsistent with the case when there are tickets then there is
> a problem but that would be a different bug.

yes, it is inconsistent also with the case when nonempty - when I get a ticket, it looks like:

$ klist
Ticket cache: KEYRING:persistent:1001:1001
Default principal: kvolny
...


or, on my Fedora 19:

$ klist
Ticket cache: DIR::/run/user/1000/krb5cc/tkt
Default principal: kvolny


so the only case where the cache location is not printed is when it is empty and not a FILE or DIR (er, is there anything else than FILE, DIR and KEYRING?)


(In reply to Nalin Dahyabhai from comment #3)
> If it's a KEYRING: cache, we don't include the cache name.  For FILE: and
> DIR:, we do.

thanks for correcting the subject; so, if empty then the "persistent:1001:1001" part from the above example is unknown?

then I'd still prefer something like

klist: No credentials cache found (ticket cache KEYRING:[unitialised])

Comment 7 Nalin Dahyabhai 2014-01-17 19:14:36 UTC

In 1.12.1 and later, this is going to look more like:
klist: Credentials cache keyring 'persistent:2510:2510' not found

Would it be a lot of trouble for you if we switched to adopting that form of this fix?

Comment 8 Patrik Kis 2014-01-20 08:32:50 UTC

(In reply to Nalin Dahyabhai from comment #7)
> In 1.12.1 and later, this is going to look more like:
> klist: Credentials cache keyring 'persistent:2510:2510' not found
> 
> Would it be a lot of trouble for you if we switched to adopting that form of
> this fix?

From qa point of view it does not really matter, if the test script is changed now or with rebase (that probably will come sooner or later). On the other hand the error message itself is descriptive enough in either form so I see no reason to add an extra patch to the current base. So IMHO, if there is not other reason than help the further rebase testing I'd keep it as it is for now.
Checking error messages in tests are always problematic as they tend to develop, but they can be easily fixed.

Comment 9 Ludek Smid 2014-06-13 09:24:23 UTC

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.