blob: 20c86d359162f7b9a8c0986f7678950290ff598a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I need to classify this bug report into one of the given categories. Let's start by reading through the problem description carefully.
The user is encountering SELinux denials when running qemu-kvm on CentOS Stream 9. The specific operations being denied are read access on 'max_map_count', and then open and getattr accesses on '/proc/sys/vm/max_map_count'. These issues were resolved by creating a custom SElinux module, which suggests that the problem lies with the security policy rather than QEMU itself.
Looking at the possible categories: mistranslation relates to incorrect mapping in user-mode assembly. Since this is about SELinux permissions and file access, it's more related to system-level security rather than translation issues or performance.
The bug report mentions qemu-kvm specifically, which is a hypervisor. However, the problem isn't with KVM's functionality but with its permission under SELinux. The logs indicate that qemu-kvm lacks the necessary permissions to access certain files, leading to denial messages.
SELinux policies are managed through modules and contexts. The user had to create a custom module to grant the required permissions, which points towards an issue with how QEMU is handled by the security policy. Therefore, this isn't a bug in the hypervisor's code but rather a misconfiguration or missing rule in the SELinux policy.
The category 'hypervisor' would relate more to issues within KVM itself, like virtualization features not working. In this case, it's about the permissions, which falls under how QEMU/KVM interacts with the system's security model.
So, considering all this, the appropriate category is 'hypervisor' because it pertains to qemu-kvm's interaction with the system and its required permissions.
</think>
hypervisor
|