all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Oguz Bektas <o.bektas@proxmox.com>
Subject: Re: [pve-devel] [PATCH container] fix #3313: recover unprivileged bit from old config during pct restore
Date: Tue, 23 Feb 2021 10:00:33 +0100	[thread overview]
Message-ID: <e25b4311-61a2-57c3-ffb9-fd64f6ccad33@proxmox.com> (raw)
In-Reply-To: <20210222150353.1449090-1-o.bektas@proxmox.com>

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) {
> 





      parent reply	other threads:[~2021-02-23  9:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-22 15:03 Oguz Bektas
2021-02-23  7:22 ` Fabian Ebner
2021-02-23  9:00 ` Thomas Lamprecht [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e25b4311-61a2-57c3-ffb9-fd64f6ccad33@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=o.bektas@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal