[libvirt] [PATCH 2/3] tests: Only use privileged mode if Qemu user and group exists

Martin Kletzander mkletzan at redhat.com
Tue Apr 8 13:03:55 UTC 2014


On Tue, Apr 08, 2014 at 12:52:36PM +0100, Daniel P. Berrange wrote:
>On Tue, Apr 08, 2014 at 01:47:14PM +0200, Martin Kletzander wrote:
>> On Tue, Apr 08, 2014 at 12:49:25PM +0200, Guido Günther wrote:
>> >On Tue, Apr 08, 2014 at 10:09:59AM +0100, Daniel P. Berrange wrote:
>> >>On Mon, Apr 07, 2014 at 04:40:24PM -0600, Eric Blake wrote:
>> >>> On 04/07/2014 02:02 AM, Guido Günther wrote:
>> >>> > When building packages in a clean chroot the QEMU_USER and QEMU_GROUP
>> >>> > don't exist making VirQemuDriverConfigNew fail with privileged=true.
>> >>> >
>> >>> > Avoid that by not requiring priviliged mode and skipping tests that need
>> >>>
>> >>> s/priviliged/privileged/
>> >>>
>> >>> > it.
>> >>> > ---
>> >>> >  tests/qemuxml2argvtest.c | 24 ++++++++++++++++--------
>> >>> >  1 file changed, 16 insertions(+), 8 deletions(-)
>> >>>
>> >>> Seems like this is what avoids the fail pointed out in 1/3.  It still
>> >>> feels fishy that our testsuite is that dependent on the system (ideally,
>> >>> we'd provide a way to mock things up so that creating the config file
>> >>> NEVER fails when run from the testsuite, even if the uid doesn't exist -
>> >>> because we shouldn't be probing the live system, only our mockups).  I'd
>> >>> wait for a second opinion on whether this patch is papering over a
>> >>> bigger problem of depending on the current system state, or whether it
>> >>> is an acceptable way to avoid the issue without investing the effort to
>> >>> tackle at the uid lookup level.
>> >>
>> >>IMHO we should be passing  privileged == false unconditionally, so that
>> >>we always skip any magic username lookups.
>> >
>> >I would have done that but Martin's 29151830e468f1a9d8006a62702591958a4e3481
>> >did the opposite, so o.k. to revert that?
>>
>> Reverting that will make *tune tests fail.  We could, however, create
>> our own test config instead of virQEMUDriverConfigNew() or add a
>> parameter to it which will decide on what to do, the least being:
>
>What about passing 'false' to ConfigNew() but then manually
>set  'cfg->privileged = true' on the object we get back.
>

That could work.  All tests passed on my setup like that.  And it
doesn't seem weird since we're playing with the config a lot in the
tests.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140408/a1d77b0b/attachment-0001.sig>


More information about the libvir-list mailing list