1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I need to classify this bug report into one of the given categories. Let me read through the problem description carefully.
The user reports that when using both `-sandbox on,elevateprivileges=deny` and `-daemonize`, QEMU fails to launch. However, without `elevateprivileges=deny`, it works fine even with `-daemonize`.
Hmm, so what's happening here? The issue seems related to the interaction between the sandbox option and daemonizing. The sandbox is a security feature in QEMU that restricts certain privileges. When `elevateprivileges=deny` is set, it prevents QEMU from running with elevated privileges, which might be necessary for some operations.
When you run QEMU normally without `-daemonize`, it runs as the current user. But when you use `-daemonize`, QEMU forks into the background and often needs to drop privileges or adjust its process context. If `elevateprivileges=deny` is set, maybe there's a conflict during this daemonization process because the sandbox restrictions are making it impossible to proceed.
Looking at the categories provided: device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
The bug is about permissions related to privilege elevation when using the sandbox with daemonize. The key issue is that QEMU can't start under these conditions because of a permission problem or incorrect handling of privileges during daemonization.
So the category that best fits here is 'permissions' since it's about how QEMU handles privilege changes, especially when running in daemon mode.
</think>
permissions
|