CEPH filesystem development
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Josh Durgin <josh.durgin@dreamhost.com>
Cc: libvir-list@redhat.com, ceph-devel@vger.kernel.org
Subject: Re: [PATCH v5 4/4] qemu/rbd: improve rbd device specification
Date: Wed, 16 Nov 2011 08:40:14 -0700	[thread overview]
Message-ID: <4EC3D95E.50903@redhat.com> (raw)
In-Reply-To: <4EC313D8.6040507@dreamhost.com>

[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]

On 11/15/2011 06:37 PM, Josh Durgin wrote:
>> The command line that we pass to qemu gets logged.  But what happens if
>> the secret was marked as ephemeral - could we be violating the premise
>> of not exposing passwords to too broad an audience?  Or are we already
>> safe in that the log entries created by virCommand can only be exposed
>> to users that already can get at the secret information by other means?
> 
> The secret can be read from the command line of the running process,
> which is even less secure than the log. I'm working on passing the
> secret via the qemu monitor instead of the command line, which will
> avoid both issues.
> 
>> Maybe this means we should we be adding capabilities into virCommand to
>> prevent the logging of the actual secret (whether base64-encoded or
>> otherwise), and instead log an alternate string?  That is, should
>> virCommand be tracking parallel argv arrays; the real array passed to
>> exec() but never logged, and the alternate array (normally matching the
>> real one, but which can differ in this particular case of passing an
>> argument that contains a password)?

Given your arguments (that ps can read argv of qemu, even if we hid it
from libvirt logs, and that we will be moving to a monitor command as
soon as qemu supports one), I see no reason to hack up virCommand to
support alternate log output.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

  reply	other threads:[~2011-11-16 15:40 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-20 18:01 [RFC PATCH v3 0/4] Improve Ceph Qemu+RBD support Josh Durgin
2011-10-20 18:01 ` [RFC PATCH v3 1/4] secret: add Ceph secret type Josh Durgin
2011-10-27  8:28   ` Daniel P. Berrange
2011-10-28 16:33     ` [libvirt] " Eric Blake
2011-10-28 16:42       ` Eric Blake
2011-10-28 17:41     ` Eric Blake
2011-10-28 18:47       ` Josh Durgin
2011-10-28 18:56         ` Eric Blake
2011-10-20 18:01 ` [RFC PATCH v3 2/4] storage: add auth to virDomainDiskDef Josh Durgin
2011-10-27  8:33   ` Daniel P. Berrange
2011-10-28 18:53     ` [libvirt] " Eric Blake
2011-10-28 19:15       ` Josh Durgin
2011-10-28 21:19         ` [PATCH 1/1] Use a common xml type for ceph secret usage Josh Durgin
2011-10-28 22:03           ` Eric Blake
2011-10-20 18:01 ` [RFC PATCH v3 3/4] qemu: pass virConnectPtr into Domain{Attach,Detach}* Josh Durgin
2011-10-27  8:33   ` Daniel P. Berrange
2011-10-31 19:14     ` [libvirt] [RFC PATCH v3 3/4] qemu: pass virConnectPtr into Domain{Attach, Detach}* Eric Blake
2011-10-20 18:01 ` [RFC PATCH v3 4/4] qemu/rbd: improve rbd device specification Josh Durgin
2011-10-27  8:38   ` Daniel P. Berrange
2011-10-28 21:19     ` [PATCH v4 " Josh Durgin
2011-10-31 20:02       ` Eric Blake
2011-11-01  1:29         ` [PATCH v5 " Josh Durgin
2011-11-16  0:05           ` Eric Blake
2011-11-16  1:37             ` Josh Durgin
2011-11-16 15:40               ` Eric Blake [this message]
2011-11-16 10:25             ` [libvirt] " Daniel P. Berrange
2011-10-27  5:19 ` [RFC PATCH v3 0/4] Improve Ceph Qemu+RBD support Sage Weil

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=4EC3D95E.50903@redhat.com \
    --to=eblake@redhat.com \
    --cc=ceph-devel@vger.kernel.org \
    --cc=josh.durgin@dreamhost.com \
    --cc=libvir-list@redhat.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