Re: [Qemu-devel] [PATCH v3 09/11] authz: add QAuthZListFile object type for a file access control list

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jun 20, 2018 at 12:38:42PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > On Wed, Jun 20, 2018 at 12:29:38PM +0100, Dr. David Alan Gilbert wrote:
> > > * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > > > On Wed, Jun 20, 2018 at 11:58:01AM +0100, Dr. David Alan Gilbert wrote:
> > > > > * Daniel P. Berrangé (berrange@redhat.com) 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.
> > > 
> > > But if I have a VNC/NBD/etc listening, won't it be bound to the old
> > > object, so I can't delete the old object?
> > 
> > That's ok actually - the network servers merely record the ID of the
> > authz object. They resolve that to an actual object instance at the
> > time they do the authorization check, and failsafe to DENY if it is
> > missing. So you can safely delete & recreate on the fly.
> 
> OK, that needs documenting; binding it at the time of parsing wouldn't
> be surprising to anyone except for that use.

I'll document that explicitly against each network service that I wire this
functionality up to, in the second dependent patch series.


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 :|