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

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

 



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

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux