From nobody Tue Feb 10 09:24:53 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1679916135; cv=none; d=zohomail.com; s=zohoarc; b=hSPpgVVOlwNwh13evE8qPKsgKa7t9+d9joFq7/58K1HoNHWh57rXUOaoGtEGJCojAlDn3sNvjHrPBJk3FlDildmFly6sY+DwQu4+Sur9hLu8vvLQyEgrCcQPtlxwyZblNXnOdANuOE9YoiVRBczEybVsdZYqW+QGUAKUgyxpgdY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1679916135; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=/CMaJ8DKZ+0NnO/nAqDa43Rgtsg8DwOPbeddbM+gj6Y=; b=WOYrpbWcdumUsxqgllVK1Gf9Win4FQH6sfCmGXP/BGIvgKuXwi+L8aDuDtTnyhShNw7WOaZl+M5SPCfJRs3+QLGFWfj6wbObNG0SpzsGPPPHSXbYL4DtOA0xKqrwbOKKu6jFvj6VZ+9f8zzUkyQ/yvEXWWL4YyLmzNu28kS4OXA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.zohomail.com with SMTPS id 1679916135111536.1805184508297; Mon, 27 Mar 2023 04:22:15 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-402-FSrbkTX_OROuvsWBxz3JJA-1; Mon, 27 Mar 2023 07:22:10 -0400 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0E7AA3C0E44A; Mon, 27 Mar 2023 11:22:08 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id F3376140E949; Mon, 27 Mar 2023 11:22:05 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id D274B19465A2; Mon, 27 Mar 2023 11:22:00 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 7E030194658F for ; Mon, 27 Mar 2023 11:21:54 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 5F5EA492B0A; Mon, 27 Mar 2023 11:21:54 +0000 (UTC) Received: from localhost.localdomain (unknown [10.43.2.39]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0482B492C3E for ; Mon, 27 Mar 2023 11:21:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679916134; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=/CMaJ8DKZ+0NnO/nAqDa43Rgtsg8DwOPbeddbM+gj6Y=; b=L0AwfgCeecSm5+9/uFd/Tmn5QqIilDOq+YI3yOPSsIHd0i7sY2NEGDpv+i+E2MiTMqsq/4 4JV/E+4vGUndxb70ZJ3p/RYX0EhRyC8n8CitgtPQZWVo6qyZfVHxdaz57LbNgaDH1bc4uD rYfu5e0fcb0o/ugQYqJL7dJO+Bekn3Q= X-MC-Unique: FSrbkTX_OROuvsWBxz3JJA-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH] virauth: Report error on empty auth result Date: Mon, 27 Mar 2023 13:21:51 +0200 Message-Id: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1679916136842100001 Content-Type: text/plain; charset="utf-8"; x-default="true" When opening a connection, it may be necessary to provide user credentials, or some additional info (e.g. whether to trust an ssh key). We have a special API for that: virConnectOpenAuth() where and additional callback can be passed. This callback is then called with _virConnectCredential struct filled partially and it's callback's responsibility to get desired data (e.g. by prompting user) and store it into .result member of the struct. But we document the callback behaviour as: If an interaction cannot be filled, fill in NULL and 0. (meaning fill in NULL and return 0) But this does not really fly with the way callback is called. So far, we have three places where the callback is called: 1) remoteAuthInteract() 2) virAuthGetUsernamePath() 3) virAuthAskCredential() Now, 1) just grabs whatever the client side provided and sends it to the other side via RPC. All interesting work takes place at 2) and 3). And the usual pattern in which these two are called is: if (!(cred =3D wrapper())) return -1; where wrapper() is a function that firstly tries to get data from a config file or URI itself. The wrappers are named virAuthGetUsername() for virAuthGetUsernamePath() and virAuthGetPassword() for virAuthAskCredential(). All wrappers do report error on failure. Except, when the user provided callback set the struct member to NULL. Then they both return NULL without setting any error. This then leads to the generic error message: error : An error occurred, but the cause is unknown Since we failed to get desired credential data, we can't proceed (what data should we pass down to the auth layer, say ssh?) and have to fail. But, we can produce an error message that'll hopefully point users in the right direction. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D2181235 Signed-off-by: Michal Privoznik Reviewed-by: Martin Kletzander --- src/util/virauth.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/util/virauth.c b/src/util/virauth.c index 7b4a1bd8a5..d1f32f8e6d 100644 --- a/src/util/virauth.c +++ b/src/util/virauth.c @@ -176,7 +176,8 @@ virAuthGetUsernamePath(const char *path, cred.result =3D NULL; cred.resultlen =3D 0; =20 - if ((*(auth->cb))(&cred, 1, auth->cbdata) < 0) { + if ((*(auth->cb))(&cred, 1, auth->cbdata) < 0 || + !cred.result) { virReportError(VIR_ERR_AUTH_FAILED, "%s", _("Username request failed")); VIR_FREE(cred.result); @@ -310,7 +311,8 @@ virAuthAskCredential(virConnectAuthPtr auth, =20 ret->prompt =3D prompt; =20 - if (auth->cb(ret, 1, auth->cbdata) < 0) { + if (auth->cb(ret, 1, auth->cbdata) < 0 || + !ret->result) { virReportError(VIR_ERR_OPERATION_FAILED, "%s", _("failed to retrieve user response for authenticat= ion callback")); return NULL; --=20 2.39.2