[pdm-devel] [PATCH datacenter-manager v3 04/23] server: add probe-tls endpoint

[Dominik Csapak]

On 8/21/25 1:46 PM, Lukas Wagner wrote:
> On Thu Aug 21, 2025 at 10:39 AM CEST, Dominik Csapak wrote:
>> so that we can probe pve endpoints regarding fingerprint/certificate
>> validity
>>
>> Signed-off-by: Dominik Csapak <d.csapak at proxmox.com>
>> ---
>>   server/src/api/pve/mod.rs | 36 ++++++++++++++++++++++++++++++++++--
>>   1 file changed, 34 insertions(+), 2 deletions(-)
>>
>> diff --git a/server/src/api/pve/mod.rs b/server/src/api/pve/mod.rs
>> index 1a3a725..c03d352 100644
>> --- a/server/src/api/pve/mod.rs
>> +++ b/server/src/api/pve/mod.rs
>> @@ -13,7 +13,7 @@ use proxmox_schema::property_string::PropertyString;
>>   use proxmox_section_config::typed::SectionConfigData;
>>   use proxmox_sortable_macro::sortable;
>>   
>> -use pdm_api_types::remotes::{NodeUrl, Remote, RemoteType, REMOTE_ID_SCHEMA};
>> +use pdm_api_types::remotes::{NodeUrl, Remote, RemoteType, TlsProbeOutcome, REMOTE_ID_SCHEMA};
>>   use pdm_api_types::resource::PveResource;
>>   use pdm_api_types::{
>>       Authid, RemoteUpid, HOST_OPTIONAL_PORT_FORMAT, PRIV_RESOURCE_AUDIT, PRIV_RESOURCE_DELETE,
>> @@ -27,8 +27,8 @@ use pve_api_types::{ClusterResourceKind, ClusterResourceType};
>>   
>>   use super::resources::{map_pve_lxc, map_pve_node, map_pve_qemu, map_pve_storage};
>>   
>> -use crate::connection;
>>   use crate::connection::PveClient;
>> +use crate::connection::{self, probe_tls_connection};
>>   use crate::remote_tasks;
>>   
>>   mod lxc;
>> @@ -44,6 +44,7 @@ pub const ROUTER: Router = Router::new()
>>   #[sortable]
>>   const SUBDIRS: SubdirMap = &sorted!([
>>       ("remotes", &REMOTES_ROUTER),
>> +    ("probe-tls", &Router::new().post(&API_METHOD_PROBE_TLS)),
>>       ("scan", &Router::new().post(&API_METHOD_SCAN_REMOTE_PVE)),
>>       (
>>           "realms",
>> @@ -299,6 +300,37 @@ fn check_guest_delete_perms(
>>       )
>>   }
>>   
>> +#[api(
>> +    input: {
>> +        properties: {
>> +            hostname: {
>> +                type: String,
>> +                format: &HOST_OPTIONAL_PORT_FORMAT,
>> +                description: "Hostname (with optional port) of the target remote",
>> +            },
>> +            fingerprint: {
>> +                type: String,
>> +                description: "Fingerprint of the target remote.",
>> +                optional: true,
>> +            },
>> +        },
>> +    },
>> +    access: {
>> +        permission:
>> +            &Permission::Privilege(&["/"], PRIV_SYS_MODIFY, false),
> 
> Does it make sense to require SYS_MODIFY here? Technically the user of
> the PDM API could also probe themselves, since they have the hostname
> anyway.
> Is this to limit the abuse potential of some rogue logged-in
> user hammering other servers with TLS probe requests while 'hiding' behind
> PDM?

the idea i had here was similar as to how we decided for permissions on
pve with the query download url api (there we need sys.audit + 
sys.modify on '/' or Sys.AccessNetwork on '/nodes/{node}' which we don't 
have in pdm)

the pdm is potentially in a network segment that is not reachable from
where the user sits, so the user can potentially probe internal network
resources. Even if the info leak is not dramatical, enumerating
ip/hostnames (from the certificate) can be bad.

> 
>> +    },
>> +)]
>> +/// Probe the hosts TLS certificate.
>> +///
>> +/// If the certificate is not trusted with the given parameters, returns the certificate
>> +/// information.
>> +async fn probe_tls(
>> +    hostname: String,
>> +    fingerprint: Option<String>,
>> +) -> Result<TlsProbeOutcome, Error> {
>> +    probe_tls_connection(RemoteType::Pve, hostname, fingerprint).await
>> +}
>> +
>>   #[api(
>>       input: {
>>           properties: {
>