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 207860927a 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: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This commit is contained in:
Michal Privoznik 2019-04-15 13:45:38 +02:00
parent d81d089e17
commit 0a9dcfabf8
2 changed files with 10 additions and 1 deletions

View File

@ -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);

View File

@ -416,3 +416,11 @@ int checkPaths(void)
virMutexUnlock(&m);
return ret;
}
int
virProcessRunInFork(virProcessForkCallback cb,
void *opaque)
{
return cb(-1, opaque);
}