From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id C177961BD3 for ; Thu, 22 Oct 2020 12:39:20 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B3EFC1F3E2 for ; Thu, 22 Oct 2020 12:39:20 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 31BA21F3D8 for ; Thu, 22 Oct 2020 12:39:20 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id E51C345E8A for ; Thu, 22 Oct 2020 12:39:19 +0200 (CEST) To: Proxmox Backup Server development discussion , Oguz Bektas References: <20201021140159.2250193-1-o.bektas@proxmox.com> <1603353403.2oxwp8ptb8.astroid@nora.none> <20201022091729.GA14703@gaia.proxmox.com> From: Thomas Lamprecht Message-ID: <9e3ec247-1bb1-7975-fba8-e283c3025d1e@proxmox.com> Date: Thu, 22 Oct 2020 12:39:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Thunderbird/82.0 MIME-Version: 1.0 In-Reply-To: <20201022091729.GA14703@gaia.proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL -0.125 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox-backup] add datastore info api call X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 10:39:20 -0000 On 22.10.20 11:17, Oguz Bektas wrote: > hi, >=20 > On Thu, Oct 22, 2020 at 10:02:23AM +0200, Fabian Gr=C3=BCnbichler wrote= : >> >> why READ and not AUDIT | BACKUP ? why partial if you only pass a singl= e=20 >> privilege? >=20 > i thought the minimum privilege should be view. one might want to add a= > datastore where only read access is given to them, to be able to restor= e > backups from it for example. imposing audit/backup privs would prevent > this, afaict >=20 >> >>> + }, >>> +)] >>> +/// Get information about the datastore. >>> +/// >>> +/// Provides PBS node fingerprint, address and datastore name >>> +pub fn info( >>> + store: String, >>> + _info: &ApiMethod, >>> + _rpcenv: &mut dyn RpcEnvironment, >>> +) -> Result { >>> + let _datastore =3D DataStore::lookup_datastore(&store)?; >>> + let cert =3D CertInfo::new()?; >>> + let fingerprint =3D cert.fingerprint()?; >>> + >>> + // get all possible interface IP addresses since there's >>> + // no explicit way to tell which is needed >>> + let (config, _) =3D network::config()?; >>> + let mut address_list =3D Vec::new(); >>> + for (_ , interface) in config.interfaces.iter() { >>> + if let Some(cidr) =3D &interface.cidr { >>> + address_list.push(cidr.to_owned()); >>> + } >>> + } >> >> doesn't this leak information that the user would/should not have acce= ss=20 >> to? I mean, if I can do an API call I already have some way to reach t= he=20 >> PBS server and we could just default to that on the client side..=20 >> possibly it would make sense to declare some interface as the=20 >> 'external/public' one and return that if configured, but just returnin= g=20 >> all addresses of all interfaces seems a bit much.. >=20 > yes, i wasn't sure how to handle this since in PVE we just take the > corosync link but here it can be any interface. >=20 > i do like the suggestion to declare an interface the "public" one. > but there could be multiple interfaces being utilized as well (like f.e= =2E > if the server has 2 addresses on two different subnets, with different > datastores). then it would make things harder. >=20 > i'm open to different suggestions. >=20 The gui, or the CLI client could really just add the host/address used to= make the API call and put it into the presented encoded information. One would have the client IP through the rpcenv, and could make some deci= sion based on that, theoretically, but I'd prefer the "client should fill in" = approach over this.