All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Julia Suvorova <jusual@mail.ru>
Cc: "Eric Blake" <eblake@redhat.com>,
	qemu-devel@nongnu.org, "Jim Mussared" <jim@groklearning.com>,
	"Steffen Görtz" <contrib@steffen-goertz.de>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Joel Stanley" <joel@jms.id.au>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] monitor: Add whitelist support for QMP commands
Date: Mon, 11 Feb 2019 16:20:02 +0000	[thread overview]
Message-ID: <20190211162002.GH27585@redhat.com> (raw)
In-Reply-To: <f45e14e3-5866-b2fa-9ed8-aa7d8e33d478@mail.ru>

On Mon, Feb 11, 2019 at 07:15:58PM +0300, Julia Suvorova wrote:
> 
> 
> On 11.02.2019 18:51, Daniel P. Berrangé wrote:
> > On Thu, Jan 31, 2019 at 03:03:21PM -0600, Eric Blake wrote:
> > > On 1/31/19 2:26 PM, Julia Suvorova via Qemu-devel wrote:
> > > > The whitelist option allows to run a reduced monitor with a subset of
> > > > QMP commands. This allows the monitor to run in secure mode, which is
> > > > convenient for sending commands via the WebSocket monitor using the
> > > > web UI. This is planned to be done on micro:bit board.
> > > > 
> > > > The list of allowed commands should be written to a file, one per line.
> > > > The command line will look like this:
> > > >      -mon chardev_name,mode=control,whitelist=path_to_file
> > > > 
> > > > Signed-off-by: Julia Suvorova <jusual@mail.ru>
> > > > ---
> > > 
> > > > -void monitor_init(Chardev *chr, int flags)
> > > > +static void process_whitelist_file(Monitor *mon, const char *whitelist_file)
> > > > +{
> > > > +    char cmd_name[256];
> > > > +    FILE *fd = fopen(whitelist_file, "r");
> > > 
> > > If you use qemu_open() here (followed by fdopen if you still prefer
> > > fscanf over read), then you can support "/dev/fdset/NNN" to
> > > auto-magically support someone passing in the whitelist via an inherited
> > > file descriptor, rather than having to be somewhere on disk that qemu
> > > can directly open().
> > > 
> > > > +
> > > > +    if (fd == NULL) {
> > > > +        error_report("Could not open whitelist file: %s", strerror(errno));
> > > > +        exit(1);
> > > > +    }
> > > > +
> > > > +    mon->whitelist = g_hash_table_new_full(g_str_hash,
> > > > +                                           g_str_equal,
> > > > +                                           g_free,
> > > > +                                           NULL);
> > > > +
> > > > +    g_hash_table_add(mon->whitelist, g_strdup("qmp_capabilities"));
> > > > +    g_hash_table_add(mon->whitelist, g_strdup("query-commands"));
> > > > +
> > > > +    while (fscanf(fd, "%255s", cmd_name) == 1) {
> > > 
> > > %255s fits your cmd_name array declaration and stops consuming at either
> > > 255 bytes or at the first whitespace encountered, but where do you check
> > > for overflow from a file that passes more than 255 non-whitespace bytes
> > > without a newline?  Also, this is a bit sloppy in that it skips all
> > > leading whitespace, rather than ensuring that the user actually passed
> > > newline-separated command names.  Does glib provide any interfaces for
> > > more easily reading in an array of lines from a file?
> > 
> > With glib, normally you'd use:
> > 
> >    char *content;
> >    gsize len;
> >    GError *err = NULL;
> >    char **lines;
> > 
> >    g_file_get_contents(filename, &contnet, &len, &err)
> 
> With g_file_get_contents() I won't be able to do qemu_open() and support
> "/dev/fdset/NNN". The workaround seems to me unnecessarily complex.

Yes, its a question of whether the /dev/fdset/NNN feature is needed or
not. At the very least though you should be using getline() rather than
fscanf so that we don't have a large hardcoded buffer on the stack.

> 
> >    lines = g_str_split(content, "\n", 0);
> > 
> >    g_free(content);
> > 
> >    ...do something with lines
> > 
> >    g_strfreev(lines);
> > 
> > 
> > The GIO library provides higher level functions for I/O but we don't
> > use that in QEMU

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

  reply	other threads:[~2019-02-11 16:41 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 20:26 [Qemu-devel] [PATCH] monitor: Add whitelist support for QMP commands Julia Suvorova
2019-01-31 20:31 ` no-reply
2019-01-31 20:32 ` no-reply
2019-01-31 21:03 ` Eric Blake
2019-01-31 21:51   ` Julia Suvorova
2019-02-11 15:51   ` Daniel P. Berrangé
2019-02-11 16:15     ` Julia Suvorova
2019-02-11 16:20       ` Daniel P. Berrangé [this message]
2019-02-01  3:11 ` Stefan Hajnoczi
2019-02-01  9:14 ` Markus Armbruster
2019-02-11 15:42   ` Julia Suvorova
2019-02-12  7:13     ` Markus Armbruster
2019-02-21 17:27       ` Julia Suvorova
2019-03-11 17:31         ` Markus Armbruster

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=20190211162002.GH27585@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=contrib@steffen-goertz.de \
    --cc=eblake@redhat.com \
    --cc=jim@groklearning.com \
    --cc=joel@jms.id.au \
    --cc=jusual@mail.ru \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@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 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.