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 17:14 +0200, Avi Kivity wrote:
> On 01/05/2011 04:57 PM, Alex Williamson wrote:
> > 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.
> >
> 
> qemu might not actually own the file, just have rw permissions.  Or it 
> might own the file and selinux may prevent it from changing the 
> permissions.  Or it may die before the reverse chmod and leave things 
> not as they were.
> 
> > 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?
> 
> No idea really.  What's the kernel's motivation for keeping it ro?  Sanity?
> 
> I'd guess libvirt is the one to do it, but someone more familiar with 
> device assignment / pci (you?) should weigh in on this.

I think I'll try the kernel first.  Digging back through bitkeeper, this
file has been read-only since it was introduced.  It looks like maybe
the enabling/disabling write was a request by Linus, so perhaps it's
simply a bug that the file never got S_IWUSR permission when the extra
logic was added.  If so, there's no point in qemu or libvirt working
around a trivial kernel bug.  Thanks,

Alex