From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 9EBCC69232 for <pve-devel@lists.proxmox.com>; Tue, 23 Feb 2021 10:00:34 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8A9E61A8E2 for <pve-devel@lists.proxmox.com>; Tue, 23 Feb 2021 10:00:34 +0100 (CET) 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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 122381A8D4 for <pve-devel@lists.proxmox.com>; Tue, 23 Feb 2021 10:00:34 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id D5437462C5 for <pve-devel@lists.proxmox.com>; Tue, 23 Feb 2021 10:00:33 +0100 (CET) Message-ID: <e25b4311-61a2-57c3-ffb9-fd64f6ccad33@proxmox.com> Date: Tue, 23 Feb 2021 10:00:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:86.0) Gecko/20100101 Thunderbird/86.0 Content-Language: en-US To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Oguz Bektas <o.bektas@proxmox.com> References: <20210222150353.1449090-1-o.bektas@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <20210222150353.1449090-1-o.bektas@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.056 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [lxc.pm] Subject: Re: [pve-devel] [PATCH container] fix #3313: recover unprivileged bit from old config during pct restore 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: Tue, 23 Feb 2021 09:00:34 -0000 On 22.02.21 16:03, Oguz Bektas wrote: > since pct defaults to privileged containers, it restores the container > as privileged when `--unprivileged 1` is not passed. > > instead we should check the old configuration and retrieve it > from there. > > this way, when one creates an unprivileged container on GUI, it will be > still restored as unprivileged via pct (without having to pass > `--unprivileged 1` parameter) > some comments on top of Fabis review (thanks for that!) > Signed-off-by: Oguz Bektas <o.bektas@proxmox.com> > --- > src/PVE/API2/LXC.pm | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm > index 8ce462f..4168a7c 100644 > --- a/src/PVE/API2/LXC.pm > +++ b/src/PVE/API2/LXC.pm > @@ -362,6 +362,10 @@ __PACKAGE__->register_method({ > # 'lxc.idmap' entries. We need to make sure that the extracted contents > # of the container match up with the restored configuration afterwards: > $conf->{lxc} = $orig_conf->{lxc}; > + > + # we also need to make sure the privileged/unprivileged bit is recovered > + # from the old config if the parameter is not passed also shorten the comment when sending a v2, either omit it as its clear what happens and this is not a manual edge case like "lxc" (which is not handled by our API). If use a short "ensure to restore privileged level if not overwritten", but its just redundant.. > + $conf->{unprivileged} = $orig_conf->{unprivileged} if !defined $unprivileged && $orig_conf->{unprivileged}; 1. seems like a pretty long line, is this under the 100 cc max? 2. should the check be: !defined($unprivileged) && defined($orig_conf->{unprivileged}); 3. nit: we normally use parentheses for defined() > } > } > if ($storage_only_mode) { >