On Tue, Apr 12, 2011 at 9:19 AM, Daniel P. Berrange <berra...@redhat.com> wrote: > On Tue, Apr 12, 2011 at 10:10:44AM +0200, Kevin Wolf wrote: >> Am 12.04.2011 09:52, schrieb Daniel P. Berrange: >> > - If the -drive specification has readonly=on (thus O_RDONLY to >> > open(2) call) , I expect QEMU (or the kernel) to forbid the >> > "eject" command on the host CDROM. This should prevent two guests >> > interfering seriously with each other. >> > >> > So I think using O_EXCL would be OK, in the case where the block >> > driver was host_cdrom and readonly=off. >> >> This would overload readonly with a completely unrelated option (should >> eject be allowed). Doesn't sound like a great idea. > > Use of the "host_cdrom" block driver enables passthrough of > commands to the host device. > > Use of "readonly" is what controls whether individual passthrough > commands are actually permitted. > > To me, "readonly" means don't allow anything that would impact > another guests view of the file/device. So forbidding 'eject' > is within scope of that IMHO.
I agree with Kevin here. You're overloading the option. Today I doubt readonly will prevent the eject/lock ioctls but I haven't tested. I'm becoming more convinced now that we should be using O_EXCL. Like you say, forcing raw gives us the option to share the device for reading without allowing the dangerous ioctls. Stefan