qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 09/11] authz: add QAuthZListFile object type


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH v3 09/11] authz: add QAuthZListFile object type for a file access control list
Date: Wed, 20 Jun 2018 12:11:07 +0100
User-agent: Mutt/1.9.5 (2018-04-13)

On Wed, Jun 20, 2018 at 11:58:01AM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (address@hidden) wrote:
> > Add a QAuthZListFile object type that implements the QAuthZ interface. This
> > built-in implementation is a proxy around the QAtuhZList object type,
> > initializing it from an external file, and optionally, automatically
> > reloading it whenever it changes.
> > 
> > To create an instance of this object via the QMP monitor, the syntax
> > used would be:
> > 
> >       {
> >         "execute": "object-add",
> >         "arguments": {
> >           "qom-type": "authz-list-file",
> >           "id": "authz0",
> >           "parameters": {
> >             "filename": "/etc/qemu/vnc.acl",
> >         "refresh": "yes"
> >           }
> >         }
> >       }
> > 
> > If "refresh" is "yes", inotify is used to monitor the file,
> > automatically reloading changes. If an error occurs during reloading,
> > all authorizations will fail until the file is next successfully
> > loaded.
> 
> I'm curious about the 'refresh' stuff:
>   a) If refresh=no is there a way to explicitly ask for a refresh
>      when some tool knows it's finished with fiddling with the file.

If refresh=no, then you can still use  object_del + object_add to
recreate the ACL object which will cause new content to be picked
up.

>   b) am I right in thinking you're actually monitoring the directory
>      for changes and retriggering on directory changes?  So it'll
>      trigger on the normal trick of renaming the modified file over the
>      original?

I originally made the mistake of trying to monitor the file
and discovered the awfulness of inotify :-(

So, yeah, now we monitor the directory so we can trigger
reloads even when the file is editted by doing a tmpfile+rename
dance.

The inotify support in the early patch in this series is intelligent
so that if multiple objects all monitor the same directory we only
use a single inotify watch.

>   c) I'm a little concerned about making it automatic; if all the qemus
>      on a  system all wake up and reparse the file at the same time.

I don't think its a big deal in this case because the files in
question are very small. Once one QEMU reads it, the kernel will
have content in I/O cache, and the CPU overhead of parsing the JSON
will be lost in the noise given likely file sizes IMHO.

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 via email to

[Prev in Thread] Current Thread [Next in Thread]