1034690 – klist doesn't print the cache location if a KEYRING: cache doesn't exist

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1034690 - klist doesn't print the cache location if a KEYRING: cache doesn't exist

Summary: klist doesn't print the cache location if a KEYRING: cache doesn't exist

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	krb5
Sub Component:
Version:	7.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	low
Severity:	low
Target Milestone:	rc
Target Release:	---
Assignee:	Nalin Dahyabhai
QA Contact:	Patrik Kis
Docs Contact:
URL:
Whiteboard:	Regression
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2013-11-26 10:56 UTC by Karel Volný
Modified:	2014-06-18 01:08 UTC (History)
CC List:	2 users (show)
Fixed In Version:	krb5-1.11.3-36.el7
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Clones:	1572651 (view as bug list)
Environment:
Last Closed:	2014-06-13 09:24:23 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

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.

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