From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, "Markus Armbruster" <armbru@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH-for-4.2] tracing: Allow to tune tracing options via the environment
Date: Tue, 9 Jul 2019 09:58:16 +0200 [thread overview]
Message-ID: <20190709075816.GA25663@stefanha-x1.localdomain> (raw)
In-Reply-To: <87r26zah4k.fsf@dusky.pond.sub.org>
[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]
On Tue, Jul 09, 2019 at 07:53:15AM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
>
> > On Mon, Jul 08, 2019 at 12:27:12PM +0200, Philippe Mathieu-Daudé wrote:
> [...]
> >> Anyway, to stop bikeshedding this thread, can you add few lines about
> >> why not use getenv() in the HACKING?
> >
> > I don't actually think the getenv thing is a security issue in any case.
> > If there was a security problem exploitable via getenv, then the bug would
> > lie in the application invoking QEMU for not ensuring the ENV contents
> > were safe before exec'ing QEMU.
>
> Correct.
>
> > Libvirt is paranoid by default and scrubs
> > QEMU's env only keeping a specific sanitized whitelist for exactly these
> > reasons.
>
> Must have for running programs with different privileges.
>
> Corrollary: a program that does not use getenv() at all is slightly
> harder to misuse with different privileges. Irrelevant in practice,
> because libraries use getenv(), starting with ld.so.
I'll reiterate that I'm happy to merge this but would first like to know
if Philippe is satisfied with adding it just to qtest?
Let's just add it to qtest if that is enough. Otherwise let's bring it
into QEMU proper.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-07-09 8:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 17:10 [Qemu-devel] [RFC PATCH-for-4.2] tracing: Allow to tune tracing options via the environment Philippe Mathieu-Daudé
2019-07-03 17:25 ` Daniel P. Berrangé
2019-07-03 17:29 ` Philippe Mathieu-Daudé
2019-07-04 10:24 ` Stefan Hajnoczi
2019-07-04 10:28 ` Daniel P. Berrangé
2019-07-05 8:07 ` Stefan Hajnoczi
2019-07-05 9:48 ` Philippe Mathieu-Daudé
2019-07-05 13:19 ` Markus Armbruster
2019-07-05 17:53 ` Philippe Mathieu-Daudé
2019-07-06 4:02 ` Markus Armbruster
2019-07-08 9:34 ` Daniel P. Berrangé
2019-07-08 10:27 ` Philippe Mathieu-Daudé
2019-07-08 10:38 ` Daniel P. Berrangé
2019-07-09 5:53 ` Markus Armbruster
2019-07-09 7:58 ` Stefan Hajnoczi [this message]
2019-07-03 21:58 ` no-reply
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=20190709075816.GA25663@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
/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;
as well as URLs for NNTP newsgroup(s).