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