提交 0a9dcfab 编写于 作者: M Michal Privoznik

qemusecuritymock: Mock virProcessRunInFork

This test is beautiful. It checks if we haven't messed up
refcounting on security labels (well, XATTRs where the original
owner is stored). It does this by setting up tracking of XATTR
setting/removing into a hash table, then calling
qemuSecuritySetAllLabel() followed by immediate
qemuSecurityRestoreAllLabel() at which point, the hash table must
be empty. The test so beautifully written that no matter
what you do it won't fail. The reason is that all seclabel work
is done in a child process. Therefore, the hash table in the
parent is never changed and thus always empty.

There are two reasons for forking (only one of them makes sense
here though):

1) namespaces - when chown()-ing a file we have to fork() and
make the child enter desired namespace,
2) locking - because of exclusive access to XATTRs we lock the
files we chown() and this is done in a fork (see 20786092 for
more info).

While we want to fork in real world, we don't want that in a test
suite. Override virProcessRunInFork() then.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
上级 d81d089e
......@@ -107,7 +107,8 @@ typedef int (*virProcessForkCallback)(pid_t ppid,
void *opaque);
int virProcessRunInFork(virProcessForkCallback cb,
void *opaque);
void *opaque)
ATTRIBUTE_NOINLINE;
int virProcessSetupPrivateMountNS(void);
......
......@@ -416,3 +416,11 @@ int checkPaths(void)
virMutexUnlock(&m);
return ret;
}
int
virProcessRunInFork(virProcessForkCallback cb,
void *opaque)
{
return cb(-1, opaque);
}
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册