Bug 2118601

Summary:	Token data are not accessible after upgrading from RHEL-8.7 to RHEL-9.0
Product:	Red Hat Enterprise Linux 9	Reporter:	Karel Srot <ksrot>
Component:	opencryptoki	Assignee:	Than Ngo <than>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Karel Srot <ksrot>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	9.0	CC:	bugproxy, dapospis, dhorak, toneata
Target Milestone:	rc	Keywords:	Triaged, ZStream
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:
Clones:	2127873 2127879 (view as bug list)		Environment:
Last Closed:	2022-09-19 13:24:27 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:
Bug Depends On:
Bug Blocks:	2089955, 2127873, 2127879

Description Karel Srot 2022-08-16 08:54:54 UTC

Description of problem:

RHEL-8.7 contains opencryptoki opencryptoki-3.18.0 that uses tokversion = 3.12.
RHEL-9.0(.z) contains opencryptoki 3.17.0 that uses older configuration.
Since configuration files in both packages are not customized by a user, after a system upgrade the config file from 3.18 is replaced with a config file from 3.17.
See https://bugzilla.redhat.com/show_bug.cgi?id=2044179#c15 for additional details.

Version-Release number of selected component (if applicable):
opencryptoki-3.17.0-7.el9

How reproducible:
always

Steps to Reproduce:
1. Configure opencryptoki tokens on RHEL-8.7 and perform system upgrade to RHEL-9.0.
2.
3.

Actual results:
Tokens are not accessible due to incorrect config file.

Expected results:
Tokens are accessible

Comment 2 Karel Srot 2022-08-16 12:22:36 UTC

According to my testing the issue is not caused by the different config file itself. Even after restoring the configuration file token data cannot be accessed.

# pkcsconf -t
Token #3 Info:
	Label: softtok                         
	Manufacturer: IBM                             
	Model: Soft            
	Serial Number:                 
	Flags: 0x80004D (RNG|LOGIN_REQUIRED|USER_PIN_INITIALIZED|CLOCK_ON_TOKEN|SO_PIN_TO_BE_CHANGED)
	Sessions: 0/[effectively infinite]
	R/W Sessions: [information unavailable]/[effectively infinite]
	PIN Length: 4-8
	Public Memory: [information unavailable]/[information unavailable]
	Private Memory: [information unavailable]/[information unavailable]
	Hardware Version: 0.0
	Firmware Version: 0.0
	Time: 2022081608112700
# pkcs11-tool -v --module /usr/lib64/opencryptoki/libopencryptoki.so  --list-objects
Using slot 0 with a present token (0x3)

Expected:

# pkcs11-tool -v --module /usr/lib64/opencryptoki/libopencryptoki.so  --list-objects
Using slot 3 with a present token (0x3)
Public Key Object; RSA 3072 bits
  label:      id_rsa.pub
  ID:         4bb238050c2aaefbd01e0a983188b4198b2fb392
  Usage:      encrypt, verify, wrap
  Access:     local

Comment 4 Karel Srot 2022-08-25 11:54:41 UTC

Hello IBM,
may I kindly ask for a review? Is it expected that token data populated with opencryptoki v3.18 would be accessible by opencryptoki v3.17?

Comment 5 Than Ngo 2022-09-12 08:24:39 UTC

Hi Karel,

in my understanding the token data which is populated with opencryptoki v3.18 should be accessible by opencryptoki v3.17 if it is the same token data format.

Comment 7 Karel Srot 2022-09-14 09:20:34 UTC

Hi Than,
I have realized that I did a mistake during my testing and forgot to restart pkcsslotd after restoring opencryptoki.conf from backup. I have tested your scratch build and can confirm that it works well.