On 27/11/2017 12:37, Daniel P. Berrange wrote: > On Mon, Nov 27, 2017 at 12:13:24PM +0100, Paolo Bonzini wrote: >> Hm, I see what you mean now. But it would be "just" a qemu-pr-helper >> bug that it trusts the caller to have "ioctl" permissions on the file >> descriptor, wouldn't it? >> >> And it could be a feature even, since the remote QEMU process also has >> to have "connect" permissions on the qemu-pr-helper socket. So you >> could give it ioctl access *limited to persistent reservations* by >> granting the appropriate permissions on the socket. > > We can't grant access to the persistent reservation helper's socket on a > per QEMU basis. Permissions are granted on the domain type svirt_t, and > we don't want to invent a new domain type just for having access to the > PR helper. You can do so via DAC and MAC on the socket itself, or is that not enough? In other words, what are the SELinux best practices when you don't want a process to have blanket access to a permission, but you may be fine with a subset of those? If you think of unpriv_sgio=0 as a very simple MAC, this is actually the very case that the PR helper is designed for. Thanks, Paolo > So if we grant access to a global PR helper, we must have that helper > do MAC checks. Without it, QEMU has delegated actions it can't do itself > to a separate process thus escaping its MAC confinement in that area. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
