Re: [Qemu-devel] [RFC 0/3] virtiofsd: get/set log level via DBus

[Stefan Hajnoczi]

On Thu, Sep 05, 2019 at 06:40:21PM +0100, Dr. David Alan Gilbert wrote:
> * Stefan Hajnoczi (address@hidden) wrote:
> > It is likely that virtiofsd will need to support "management commands" for
> > reconfiguring it at runtime.  The first use case was proposed by Eryu Guan 
> > for
> > getting/setting the current log level.
> > 
> > I promised to try out DBus as the management interface because it has a rich
> > feature set and is accessible from most programming languages.  It should be
> > able to support all the use cases we come up with.
> > 
> > This patch series is a prototype that implements the get-log-level and
> > set-log-level management commands via DBus.  Use the new virtiofsctl tool to
> > talk to a running virtiofsd process:
> > 
> >   # dbus-run-session ./virtiofsd ...
> >   ...
> >   Using dbus address 
> > unix:abstract=/tmp/dbus-H9WBbpjk3O,guid=0be16acefb868e6025a8737f5d7124d2
> >   # export 
> > DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-H9WBbpjk3O,guid=0be16acefb868e6025a8737f5d7124d2
> >   # ./virtiofsctl set-log-level err
> > 
> > Most of the work is done by gdbus-codegen(1).  It generates code for the
> > org.qemu.Virtiofsd.xml interface definition.  Our code can use the simple
> > virtiofsd_get/set_log_level() APIs and it will make corresponding DBus 
> > calls.
> > 
> > I'm pretty happy with this approach because the code is straightforward.  It
> > hasn't even triggered seccomp failures yet :).
> 
> Yes it's less complex than I'd worried.
> Now, I do think we've got to think about how qemu in general is going to
> use dbus as people were discussing it, because then we have to think
> what the security aspects are - do we need to look at some calls only
> available to some clients etc.

The approach I took in this patch series is to launch a session bus just
for this virtiofsd.  The abstract socket unix(7) namespace used by GDBus
by default does not offer any security.  I think any process on the host
can connect to it, regardless of uid/gid.

A path like unix:path=/tmp/foo would allow us to use UNIX Domain Socket
permissions as the main security mechanism.  I'm not enthusiastic about
using SELinux or some kind of DBus-specific policy language if we can
avoid it because it's complex and obscure.

Stefan

signature.asc
Description: PGP signature