On Thu, Apr 02, 2026 at 11:12:35 -0400, Cole Robinson via Devel wrote:
This does not change behavior, but it eliminates direct usage of 'cfg->user' which makes for easier auditing
Signed-off-by: Cole Robinson <crobinso@redhat.com> --- src/qemu/qemu_process.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 7ebc038e54..a921bbcea8 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4926,6 +4926,8 @@ qemuPrepareNVRAMFileCommon(virQEMUDriver *driver, g_autoptr(virQEMUDriverConfig) cfg = virQEMUDriverGetConfig(driver); VIR_AUTOCLOSE srcFD = -1; struct qemuPrepareNVRAMHelperData data; + uid_t uid; + gid_t gid;
if (!path) return 0; @@ -4951,9 +4953,10 @@ qemuPrepareNVRAMFileCommon(virQEMUDriver *driver, data.srcFD = srcFD; data.srcPath = template;
+ qemuDomainGetImageIds(cfg, NULL, NULL, NULL, &uid, &gid); if (virFileRewrite(path, S_IRUSR | S_IWUSR, - cfg->user, cfg->group, + uid, gid, qemuPrepareNVRAMHelper, &data) < 0) {
While as you claim this doesn't change behaviour of the code, this function prepares the file to be used with a VM definition (which is available one level above in the call stack). IMO this patch should be replaced by a proper fix which passes in the definition and uses the seclabel from the definition. Otherwise it may seem that we deliberately don't want to use it, which is not the case (the correct seclabel will be applied anyways, albeit by the security driver when relabelling).