From: "Daniel P. Berrange" <berrange@redhat.com>
To: ashish mittal <ashmit602@gmail.com>
Cc: Jeff Cody <jcody@redhat.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
Ketan Nilangekar <Ketan.Nilangekar@veritas.com>,
qemu-devel <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Fam Zheng <famz@redhat.com>,
Ashish Mittal <Ashish.Mittal@veritas.com>,
John Ferlan <jferlan@redhat.com>,
Buddhi Madhav <Buddhi.Madhav@veritas.com>,
Suraj Singh <Suraj.Singh@veritas.com>,
Nitin Jerath <Nitin.Jerath@veritas.com>,
Peter Maydell <peter.maydell@linaro.org>,
Abhijit Dey <Abhijit.Dey@veritas.com>,
"Venkatesha M.G." <Venkatesha.Mg@veritas.com>,
Rakesh Ranjan <Rakesh.Ranjan@veritas.com>
Subject: Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"
Date: Fri, 24 Feb 2017 09:19:16 +0000 [thread overview]
Message-ID: <20170224091916.GD3702@redhat.com> (raw)
In-Reply-To: <CAAo6VWPWjRTE3t9myt7Q6gTnZcvP72ypTE03PCFfJkvb2UWLTA@mail.gmail.com>
On Thu, Feb 23, 2017 at 08:19:29PM -0800, ashish mittal wrote:
> Hi,
>
> Just want to check if the following mechanism for accepting the secret
> password looks OK?
>
> We have yet to internally discuss the semantics of how we plan to use
> the user-ID/password for authentication. This diff is just to
> understand how I am expected to accept the secret from the command
> line.
>
> Example specifying the username and password:
>
> $ ./qemu-io --trace enable=vxhs* --object
> secret,id=ashish,data=asd888d989s -c 'read 66000 128k'
> 'json:{"server.host": "127.0.0.1", "server.port": "9999", "vdisk-id":
> "/test.raw", "driver": "vxhs", "user": "ashish"}'
> 17396@1487908905.546890:vxhs_open_vdiskid Opening vdisk-id /test.raw
> 17396@1487908905.546969:vxhs_get_creds SecretID ashish, Password
> asd888d989s <==== NOTE!!!!!
> 17396@1487908905.546994:vxhs_open_hostinfo Adding host 127.0.0.1:9999
> to BDRVVXHSState
> 17396@1487908905.568370:vxhs_get_vdisk_stat vDisk /test.raw stat ioctl
> returned size 196616
> read 131072/131072 bytes at offset 66000
> 128 KiB, 1 ops; 0.0017 sec (72.844 MiB/sec and 582.7506 ops/sec)
> 17396@1487908905.570917:vxhs_close Closing vdisk /test.raw
> [root@rhel72ga-build-upstream qemu] 2017-02-23 20:01:45$
>
> Example where username and password are missing:
>
> [root@rhel72ga-build-upstream qemu] 2017-02-23 19:30:16$ ./qemu-io
> --trace enable=vxhs* -c 'read 66000 128k' 'json:{"server.host":
> "127.0.0.1", "server.port": "9999", "vdisk-id": "/test.raw", "driver":
> "vxhs"}'
> 16120@1487907025.251167:vxhs_open_vdiskid Opening vdisk-id /test.raw
> 16120@1487907025.251245:vxhs_get_creds SecretID user, Password (null)
> can't open device json:{"server.host": "127.0.0.1", "server.port":
> "9999", "vdisk-id": "/test.raw", "driver": "vxhs"}: No secret with id
> 'user' <==== NOTE!!!!!
> [root@rhel72ga-build-upstream qemu] 2017-02-23 19:30:25$
It is close but not quite correct approach. You're overloading a
single property to provide two different things - the username
and as a key to lookup the password secret - you want different
properties.
The 'secret' object only needs to be used for data that must be
kept private. By convention the block drivers try to use a property
'password-secret' to reference the ID of the secret object.
So, as an example, if you had a username "fred" and passwd "letmein"
then a suitable syntax would be
$ ./qemu-io \
--object secret,id=vxhspasswd,data=letmein
-c 'read 66000 128k'
'json:{"server.host": "127.0.0.1", "server.port": "9999",
"vdisk-id": "/test.raw", "driver": "vxhs",
"user": "fred", "password-secret": "xvxhspasswd"}'
(obviously in real world, we'd not send across the password
in clear text in the data= parameter of the secret - we'd
use the file= parameter instead, but its fine for dev testing.
> diff --git a/block/vxhs.c b/block/vxhs.c
> index 4f0633e..f3e70ce 100644
> --- a/block/vxhs.c
> +++ b/block/vxhs.c
> @@ -17,6 +17,7 @@
> #include "qemu/uri.h"
> #include "qapi/error.h"
> #include "qemu/uuid.h"
> +#include "crypto/secret.h"
>
> #define VXHS_OPT_FILENAME "filename"
> #define VXHS_OPT_VDISK_ID "vdisk-id"
> @@ -136,6 +137,14 @@ static QemuOptsList runtime_opts = {
> .type = QEMU_OPT_STRING,
> .help = "UUID of the VxHS vdisk",
> },
> + {
> + .name = "user",
> + .type = QEMU_OPT_STRING,
> + },
> + {
> + .name = "password",
> + .type = QEMU_OPT_STRING,
> + },
> { /* end of list */ }
> },
> };
> @@ -257,6 +266,8 @@ static int vxhs_open(BlockDriverState *bs, QDict *options,
> const char *server_host_opt;
> char *str = NULL;
> int ret = 0;
> + const char *user = NULL;
> + const char *password = NULL;
>
> ret = vxhs_init_and_ref();
> if (ret < 0) {
> @@ -320,6 +331,23 @@ static int vxhs_open(BlockDriverState *bs, QDict *options,
> goto out;
> }
>
> + /* check if we got username via the options */
> + user = qemu_opt_get(opts, "user");
> + if (!user) {
> + //trace_vxhs_get_creds(user, password);
> + user = "user";
We should not default any login credentials - if no username was
provided we should simply not use any username - if the server
mandates a username this obviously means connection would fail
and that's ok.
> + //return;
> + }
> +
> + password = qcrypto_secret_lookup_as_utf8(user, &local_err);
Instead of passing 'user' into this method, you need to call
qemu_opt_get(opts, "password-secret") and use that result
> + if (local_err != NULL) {
> + trace_vxhs_get_creds(user, password);
> + qdict_del(backing_options, str);
> + ret = -EINVAL;
> + goto out;
> + }
> + trace_vxhs_get_creds(user, password);
> +
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
next prev parent reply other threads:[~2017-02-24 9:19 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-16 22:24 [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs" ashish mittal
2017-02-17 21:42 ` Jeff Cody
2017-02-18 0:30 ` Ketan Nilangekar
2017-02-20 9:50 ` Daniel P. Berrange
2017-02-20 11:02 ` Stefan Hajnoczi
2017-02-20 11:34 ` ashish mittal
2017-02-21 10:59 ` Stefan Hajnoczi
2017-02-21 11:33 ` Daniel P. Berrange
2017-02-22 14:09 ` Stefan Hajnoczi
2017-02-22 14:22 ` Daniel P. Berrange
2017-02-22 14:44 ` Jeff Cody
2017-02-24 4:19 ` ashish mittal
2017-02-24 9:19 ` Daniel P. Berrange [this message]
2017-02-24 23:30 ` ashish mittal
2017-02-27 9:22 ` Daniel P. Berrange
2017-02-28 22:51 ` ashish mittal
2017-03-01 9:18 ` Daniel P. Berrange
2017-03-06 0:26 ` ashish mittal
2017-03-06 9:23 ` Daniel P. Berrange
2017-03-08 1:27 ` ashish mittal
2017-03-08 9:13 ` Daniel P. Berrange
2017-03-08 13:04 ` Ketan Nilangekar
2017-03-08 17:59 ` ashish mittal
2017-03-08 18:11 ` Daniel P. Berrange
2017-03-11 3:04 ` ashish mittal
2017-03-13 9:56 ` Daniel P. Berrange
2017-03-13 9:57 ` Daniel P. Berrange
2017-03-17 0:29 ` ashish mittal
2017-03-18 1:44 ` ashish mittal
2017-03-20 12:55 ` Daniel P. Berrange
2017-03-23 0:03 ` ashish mittal
2017-03-27 3:07 ` ashish mittal
2017-02-21 17:21 ` Ketan Nilangekar
2017-02-21 17:39 ` Daniel P. Berrange
2017-02-21 18:06 ` Jeff Cody
2017-02-21 18:56 ` Daniel P. Berrange
2017-02-21 19:25 ` Jeff Cody
2017-02-22 10:12 ` Daniel P. Berrange
2017-02-22 14:25 ` Stefan Hajnoczi
2017-02-20 9:44 ` Daniel P. Berrange
-- strict thread matches above, loose matches on Subject: below --
2017-02-09 5:23 Ashish Mittal
2017-02-09 6:29 ` Jeff Cody
2017-02-09 9:24 ` ashish mittal
2017-02-09 14:32 ` Jeff Cody
2017-02-09 16:14 ` ashish mittal
2017-02-09 16:50 ` Jeff Cody
2017-02-09 18:08 ` ashish mittal
2017-02-09 18:45 ` ashish mittal
2017-02-10 0:27 ` ashish mittal
2017-02-10 2:18 ` Jeff Cody
2017-02-14 20:51 ` Jeff Cody
2017-02-14 22:34 ` ashish mittal
2017-02-15 3:02 ` ashish mittal
2017-02-15 3:54 ` Jeff Cody
2017-02-15 20:34 ` ashish mittal
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=20170224091916.GD3702@redhat.com \
--to=berrange@redhat.com \
--cc=Abhijit.Dey@veritas.com \
--cc=Ashish.Mittal@veritas.com \
--cc=Buddhi.Madhav@veritas.com \
--cc=Ketan.Nilangekar@veritas.com \
--cc=Nitin.Jerath@veritas.com \
--cc=Rakesh.Ranjan@veritas.com \
--cc=Suraj.Singh@veritas.com \
--cc=Venkatesha.Mg@veritas.com \
--cc=armbru@redhat.com \
--cc=ashmit602@gmail.com \
--cc=famz@redhat.com \
--cc=jcody@redhat.com \
--cc=jferlan@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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;
as well as URLs for NNTP newsgroup(s).