public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Folke Gleumes <f.gleumes@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH container] fix #5194: delete environment variables set by pve
Date: Fri, 26 Jan 2024 13:31:23 +0100	[thread overview]
Message-ID: <doi73y6fjzxw4lkhrhhrakt6iqxzgshqr67ituhllrohenk7hu@y2oslzcp3a73> (raw)
In-Reply-To: <c06cbeaba45460d215674a1fe46249f5a7de9f61.camel@proxmox.com>

On Fri, Jan 26, 2024 at 12:39:17PM +0100, Folke Gleumes wrote:
> On Tue, 2024-01-23 at 10:51 +0100, Fabian Grünbichler wrote:
> > On January 22, 2024 11:12 am, Folke Gleumes wrote:
> > > proxmox-perl-rs set's SSL_CERT_{DIR,FILE}, which can break ssl in
> > > containers if their certificate store can't be found in the same
> > > spot.
> > > This patch explicitly unsets those variables before starting the
> > > container.
> > 
> > after a short talk with Wolfgang - this patch is probably an okay
> > stop-gap to fix the particular regression.
> If I understood things correctly, setting the env variables won't be
> necessary with the next Debian major release, so I'll add a notice to
> remove the workaround with pve 9 [0].

Just note that while it won't be necessary for us to set them *early*,
they will still be set by the `openssl-probe` if any rust code calling
into something related to that from the `openssl` crate is called.
This is already kind of annoying, but nonetheless, at host/container
boundaries we should always deal with the environment anyway.

> > 
> > but it might be nice to switch to `--clear-env` for lxc-attach with
> > corresponding options for pct to either preserve the whole env, or
> > particular variables? might be 9.0 material since it is a semantic
> > change that possibly breaks scripted use cases that rely on env
> > variables to pass along things from host to whatever they run inside
> > the
> > container.. we could introduce the options now though and also have a
> > `--keep-env` that is the default for 8.x, and flip it to default to
> > `--clear-env` with 9.0.
> Seems like a good idea. I also noticed that the lxc-attach man page
> currently states "[keep-env] is the current default behaviour  (as  of
> version  0.9),  but is is likely to change in the future". By defining
> it explicitly, we would be free to decide when to introduce the change.

Exactly.




      reply	other threads:[~2024-01-26 12:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-22 10:12 Folke Gleumes
2024-01-23  9:51 ` Fabian Grünbichler
2024-01-26 11:39   ` Folke Gleumes
2024-01-26 12:31     ` Wolfgang Bumiller [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=doi73y6fjzxw4lkhrhhrakt6iqxzgshqr67ituhllrohenk7hu@y2oslzcp3a73 \
    --to=w.bumiller@proxmox.com \
    --cc=f.gleumes@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal