Re: [PATCH v2] device-assignment: chmod the rom file before opening read/write

[Alex Williamson <alex.williamson@redhat.com>]

On Wed, 2011-01-05 at 10:57 +0200, Avi Kivity wrote:
> On 01/04/2011 08:45 PM, Alex Williamson wrote:
> > The PCI sysfs rom file is exposed read-only by default, but we need
> > to write to it to enable and disable the ROM around the read.  When
> > running as root, the code works fine as is, but when running
> > de-privileged via libvirt, the fopen("r+") will fail if the file
> > doesn't have owner write permissions.  libvirt already gives us
> > ownership of the file, so we can toggle this around the short
> > usage window ourselves.
> 
> Why is qemu in the business of chmod()ing resources?  If qemu needs 
> write access to some resource, the user needs to provide that access.

A valid argument.  I think it could also be argued that the user is
providing ownership of the file and writing to the file is part of the
low level details of the sysfs rom file API and should be handled by the
user of that API.  We basically have 3 places we could put this:

     A. kernel - Why is this file mode 0400 by default anyway if using
        it requires write access?  Set it to mode 0600 here by default.
     B. libvirt - Already does chown, why not do chmod too?  chmod and
        restore here.
     C. qemu - Owns file, chmod is trivial and part of the sysfs rom
        file API?  chmod around usage.

I chose qemu because it seemed to have the least chance of side-effects
and has the smallest usage window.  Do you prefer libvirt or kernel?
Thanks,

Alex