On Donnerstag, 16. Juli 2020 11:21:55 CEST P J P wrote: > +-- On Thu, 16 Jul 2020, Daniel P. Berrangé wrote --+ > > | > Failing to start (with a message that explains why) if one of the > | > command > | > line options is not covered by a specified security policy is not > | > unreasonable (after all, we fail to start for other cases of > | > incompatible > | > command line options as well.) > > Yes, that's right. > > | > However, we also need to cover dynamically-added devices. Aborting seems > | > very bad there, just failing to add the device seems like what we'd > | > want. > | > | Yep, aborting is simply not an option for the inner code. It all has to > | propagate to a proper Error **errp object. The ultimate entry-point at the > | CLI vs QMP then decides whether to turn the error into an abort or feed > | back to the client app. > > True, handling dynamic devices is tricky. > > Though it seems kind of uniform workflow to check for '--security' flag at > options parsing OR while handling dynamic devices at run time; It is a huge > task to cover all options/use-cases for all QEMU emulators across various > architectures.
My concern here is that just distinguishing between either 'low' or 'high' is a far too rough classification. In our preceding communication regarding 9pfs, I made clear that a) we do care about security relevant 9pfs issues, and only b) the avarage use cases (as far we know) for 9pfs are above a certain trust level. However b) does not imply 9pfs being 'unsafe', nor that we want users to refrain using it in a security relevant environment. So 9pfs would actually be somewhere in between. Best regards, Christian Schoenebeck
