On 12/14/2012 01:33 PM, Eric Blake wrote: > On 12/13/2012 12:05 PM, Osier Yang wrote: >> Since "rawio" and "cdbfilter" are only valid for "lun", this >> groups them together; And since both of them intend to allow >> the unprivledged user to use the SG_IO commands, they must be > > s/unprivledged/unprivileged/ > rawio cdbfilter result > missing missing kernel prevents SG_IO > missing no kernel prevents SG_IO > missing yes SG_IO allowed for disk > no missing kernel prevents SG_IO > no no kernel prevents SG_IO > no yes SG_IO allowed for disk > yes missing SG_IO allowed for process > yes no SG_IO allowed for process > yes yes error This table shows another reason why I don't like your naming - the defaults are screwy, when an omitted rawio means 'no', but an omitted cdbfilter means 'yes'. Corrected, the table looks like: rawio cdbfilter result missing missing kernel prevents SG_IO missing no SG_IO allowed for disk missing yes kernel prevents SG_IO no missing kernel prevents SG_IO no no error? or SG_IO allowed for disk? no yes error? or kernel prevents SG_IO? yes missing SG_IO allowed for process yes no error yes yes error? or kernel prevents SG_IO? > Why not simplify things, and have a single attribute rawio, with > multiple values? > > rawio result > missing kernel prevents SG_IO > no kernel prevents SG_IO > yes SG_IO allowed for process > cdb SG_IO allowed for disk > > where we document that 'yes' works on more kernel versions than 'cdb', > but that 'cdb' (new to 1.0.1) is more secure. Oh, another thing, what does 'cdb' mean? It happens to be an acronym that matches the kernel implementation, but it doesn't convey much meaning on its own. Given that our existing rawio='yes' merely turns on SG_IO via a capability for the entire process, and the new filtering method enables per-disk whitelisting of which disks get to use SG_IO passthrough, would it be any better to document things as: no|yes|disk and where we additionally allow 'process' as a synonym for 'yes' on input (for back-compat, we have to output 'yes', not 'process'). That is, I don't know that exposing the term 'cdb' buys us any understanding into what is really going on. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list