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.
prev parent 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