On 05/07/2018 02:02 PM, Ján Tomko wrote: > On Mon, May 07, 2018 at 12:33:20PM +0200, Eduardo Otubo wrote: >> On 07/05/2018 - 11:29:57, Christian Borntraeger wrote: >>> On 05/07/2018 05:32 AM, Yi Min Zhao wrote: >>> > 1. Problem Description >>> > ====================== >>> > If QEMU is built without seccomp support, 'elevatorprivileges' remains compiled. >>> > This option of sandbox is treated as an indication for seccomp blacklist support >>> > in libvirt. This behavior is introduced by the libvirt commits 31ca6a5 and >>> > 3527f9d. It would make libvirt build wrong QEMU cmdline, and then the guest >>> > startup would fail. >>> >>> Adding libvirt list. >>> >>> This would still fail with older QEMUs, so the question is if we should also OR instead >>> change something in libvirt. >> >> Perhaps I'm missing something here, but libvirt can differentiate between >> different versions of QEMU, therefore not calling it with wrong or outdated >> arguments. >> > > The code introduced in libvirt commit 31ca6a5 specifically looks for > 'elevateprivileges' in 'parameters' of the 'sandbox' option through > query-command-line-options. > > Outdated QEMUs should not have this option there. > > However, libvirtd does add the option by default not knowing whether it > can fail for other reasons, e.g. SECCOMP not being enabled in the > running kernel. I wonder if that is worth addressing. So you prefer the qemu patch (with cc stable) as the best solution? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
