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 44517782F9 for ; Thu, 29 Apr 2021 15:54:57 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 317391E027 for ; Thu, 29 Apr 2021 15:54:27 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (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 97B9B1E01C for ; Thu, 29 Apr 2021 15:54:26 +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 7BF3F464CB for ; Thu, 29 Apr 2021 15:46:28 +0200 (CEST) Date: Thu, 29 Apr 2021 15:46:22 +0200 (CEST) From: Lorenz Stechauner To: Thomas Lamprecht , Proxmox VE development discussion , Dominik Csapak Message-ID: <901234855.1836.1619703982799@webmail.proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.5-Rev9 X-Originating-Client: open-xchange-appsuite X-SPAM-LEVEL: Spam detection results: 1 AWL 1.414 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH storage 1/1] fix #1710: add retrieve method for storage X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2021 13:54:57 -0000 Another idea would be to introduce two new permissions: Sys.RetrieveLocal - only local/private ip addresses allowed Sys.RetrieveGlobal - all other ip addresses allowed (means only non-private= ) > On 29.04.21 15:22 Thomas Lamprecht wrote: >=20 > =20 > On 29.04.21 13:54, Dominik Csapak wrote: > > On 4/28/21 16:13, Lorenz Stechauner wrote: > >> =C2=A0 +__PACKAGE__->register_method({ > >> +=C2=A0=C2=A0=C2=A0 name =3D> 'retrieve', > >> +=C2=A0=C2=A0=C2=A0 path =3D> '{storage}/retrieve', > >> +=C2=A0=C2=A0=C2=A0 method =3D> 'POST', > >> +=C2=A0=C2=A0=C2=A0 description =3D> "Download templates and ISO image= s by using an URL.", > >> +=C2=A0=C2=A0=C2=A0 permissions =3D> { > >> +=C2=A0=C2=A0=C2=A0 check =3D> ['perm', '/storage/{storage}', ['Datast= ore.AllocateTemplate']], > >> +=C2=A0=C2=A0=C2=A0 }, > >> +=C2=A0=C2=A0=C2=A0 protected =3D> 1, > >> +=C2=A0=C2=A0=C2=A0 parameters =3D> { > >> +=C2=A0=C2=A0=C2=A0 additionalProperties =3D> 0, > >> +=C2=A0=C2=A0=C2=A0 properties =3D> { > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 node =3D> get_standard_opt= ion('pve-node'), > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 storage =3D> get_standard_= option('pve-storage-id'), > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 url =3D> { > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description =3D> "The URL = to retrieve the file from.", > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type =3D> 'string', > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }, > >=20 > > i am not quite sure if it is a good idea to have this feature > > unrestricted for everybody who can download a template > >=20 > > it possibly gives access to an internal network to which > > the users does not have access otherwise... > >=20 > > maybe we want to give the admin control over allow- and/or blocklists ? >=20 > I do not want such lists, PITA to manage for everybody. >=20 > Maybe we can just allow it only for users with Sys.Modify + Sys.Audit on = / ? >=20 > We could also enforce that it needs to be a hostname (no IP) and/or resol= ve > to something out of the priv. network ranges, at least if the aforementio= ned > privs are not set. >=20 > Another idea would be enforcing the URL to match something like /\.(iso|i= mg)$/=20 > and being not to informative on errors to avoid allowing to see which hso= t are > on/off line in a network. With that one could make this pretty safe I thi= nk. >=20 >=20 > >=20 > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 insecure =3D> { > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description =3D> "Allow TL= S certificates to be invalid.", > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type =3D> 'boolean', > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 optional =3D> 1, > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } > +=C2=A0=C2=A0=C2=A0 }, > >> +=C2=A0=C2=A0=C2=A0 }, > >> +=C2=A0=C2=A0=C2=A0 returns =3D> { > >> +=C2=A0=C2=A0=C2=A0 type =3D> "object", > >> +=C2=A0=C2=A0=C2=A0 properties =3D> { > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 filename =3D> { type =3D> = 'string' }, > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 upid =3D> { type =3D> 'str= ing' }, > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 size =3D> { > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type =3D> 'integer', > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 renderer =3D> 'bytes', > >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }, > >> +=C2=A0=C2=A0=C2=A0 }, > >> +=C2=A0=C2=A0=C2=A0 }, > >> +=C2=A0=C2=A0=C2=A0 code =3D> sub { > >> +=C2=A0=C2=A0=C2=A0 my ($param) =3D @_; > >> + > >> +=C2=A0=C2=A0=C2=A0 my @hash_algs =3D ['md5', 'sha1', 'sha224', 'sha25= 6', 'sha384', 'sha512']; > >=20 > > as written above, can be handled by api >=20 > and could be actually auto-detected too, at least optionally? All those a= re pretty > much unique already in length, IIRC.