Associated private key search needs login

[bukka]

Describe the bug

Searching for associated private key should require session with login as this is usually needed to get private keys. This is however not the case as the session does not require login:

pkcs11-provider/src/objects.c

Lines 1455 to 1457 in 4b3c201

	ret = p11prov_get_session(obj->ctx, &slotid, NULL, NULL,
	CK_UNAVAILABLE_INFORMATION, NULL, NULL, false,
	false, &session);

. This results in an error because such key is not found (unless logged in already open session is used)/

To Reproduce
Load RSA using the util function and check the debug logs. It should result in this sort of error: p11prov_obj_find_associated(): Error: 0x00000000; Error in C_FindObjects (count=0)

Expected behavior
Session should be created with login

Operating environment (please complete the following information):

• OS: Ubuntu
• Version 24.04

Token and application used (please complete the following information):

• Device: Kryotic
• PKCS11 Driver version: later version (does not matter really)
• Application: Test

Additional context

I fuond this when working on test for #536 and checking the debug logs:

[2025-08-10 22:15:11.177] [../src/util.c:68] p11prov_fetch_attributes(): Attribute| type:0x40000600 value:(nil), len:0
[2025-08-10 22:15:11.177] [../src/objects.c:1411] p11prov_obj_find(): Find objects: found 1 objects; Returning 0
[2025-08-10 22:15:11.177] [../src/objects.c:1430] p11prov_obj_find_associated(): Find associated object
[2025-08-10 22:15:11.177] [../src/session.c:907] p11prov_get_session(): Get session on slot 52, reqlogin=false, rw=false
[2025-08-10 22:15:11.177] [../src/session.c:916] p11prov_get_session(): single-shot request for slot 52
[2025-08-10 22:15:11.177] [../src/session.c:634] check_slot(): Checking Slot id=52, uri=(nil), mechtype=ffffffffffffffff, rw=false)
[2025-08-10 22:15:11.177] [../src/provider.c:621] p11prov_ctx_login_behavior(): login_behavior = 0
[2025-08-10 22:15:11.177] [../src/session.c:273] session_new(): Creating new P11PROV_SESSION session on pool 0x617fa05002a0
[2025-08-10 22:15:11.177] [../src/session.c:307] session_new(): Total sessions: 2
[2025-08-10 22:15:11.177] [../src/session.c:331] session_check(): Checked session 0 handle invalid
[2025-08-10 22:15:11.177] [../src/interface.gen.c:302] p11prov_OpenSession(): Calling C_OpenSession
[2025-08-10 22:15:11.177] [../src/session.c:80] token_session_open(): C_OpenSession ret:0 (session: 5)
[2025-08-10 22:15:11.177] [../src/interface.gen.c:357] p11prov_GetSessionInfo(): Calling C_GetSessionInfo
[2025-08-10 22:15:11.177] [../src/interface.gen.c:621] p11prov_FindObjectsInit(): Calling C_FindObjectsInit
[2025-08-10 22:15:11.177] [../src/interface.gen.c:651] p11prov_FindObjects(): Calling C_FindObjects
[2025-08-10 22:15:11.177] [../src/interface.gen.c:679] p11prov_FindObjectsFinal(): Calling C_FindObjectsFinal
[2025-08-10 22:15:11.177] [../src/objects.c:1482] p11prov_obj_find_associated(): Error: 0x00000000; Error in C_FindObjects (count=0)

I initially thought that it might be an issue for me so I investigated further but it's actually just for PSS check when public key does not have the mechanism attribute (which doesn't usually happen). But I can imagine that this make this private key check a bit limited:

pkcs11-provider/src/objects.c

Lines 608 to 631 in 4b3c201

	if (am == NULL || am->ulValueLen == 0) {
	/* The ALLOWED_MECHANISMS should be on both of the keys. But more
	* commonly they are available only on the private key. Check if we
	* have a priv key associated to this pub key and if so, use that one.
	* TODO we can try also certificate restrictions
	*/
	if (obj->class == CKO_PRIVATE_KEY) {
	/* no limitations */
	return false;
	}
	/* Try to find private key */
	priv = p11prov_obj_find_associated(obj, CKO_PRIVATE_KEY);
	if (priv == NULL) {
	return false;
	}
	am = p11prov_obj_get_attr(priv, CKA_ALLOWED_MECHANISMS);
	if (am == NULL || am->ulValueLen == 0) {
	/* no limitations */
	p11prov_obj_free(priv);
	return false;
	}
	}

. Also it could be potentially problematic in getting CKO_PRIVATE_KEY in some future use cases (if there are any). And the error is, of course, quite confusing, which was really my main issue with this.