From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <l.stechauner@proxmox.com>
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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; Thu, 29 Apr 2021 15:46:28 +0200 (CEST)
Date: Thu, 29 Apr 2021 15:46:22 +0200 (CEST)
From: Lorenz Stechauner <l.stechauner@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
Dominik Csapak <d.csapak@proxmox.com>
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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=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 <t.lamprecht@proxmox.com> 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.