Re: [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot

[George Dunlap <george.dunlap@citrix.com>]

On 11/06/2018 09:14 AM, Paul Durrant wrote:
>> -----Original Message-----
>> From: Xen-devel [mailto:xen-devel-bounces@lists.xenproject.org] On Behalf
>> Of George Dunlap
>> Sent: 05 November 2018 18:07
>> To: xen-devel@lists.xenproject.org
>> Cc: Anthony Perard <anthony.perard@citrix.com>; Ian Jackson
>> <Ian.Jackson@citrix.com>; Wei Liu <wei.liu2@citrix.com>; George Dunlap
>> <George.Dunlap@citrix.com>
>> Subject: [Xen-devel] [PATCH v4 3/6] tools/dm_restrict: Ask QEMU to chroot
>>
>> When dm_restrict is enabled, ask QEMU to chroot into an empty directory.
>>
>> * Create /var/run/qemu/root-domid (deleting the old one if it's there)
> 
> This does not appear to match the code: the path should be /var/run/qemu-root-<domid> AFAICT

Indeed, I forgot to update this.  I can fix this up on check-in.

>> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
>> index 26eb16af34..ad3efcc783 100644
>> --- a/tools/libxl/libxl_dm.c
>> +++ b/tools/libxl/libxl_dm.c
>> @@ -1410,9 +1410,48 @@ static int
>> libxl__build_device_model_args_new(libxl__gc *gc,
>>          }
>>      }
>>
>> -    if (libxl_defbool_val(b_info->dm_restrict))
>> +    if (libxl_defbool_val(b_info->dm_restrict)) {
>> +        char *chroot_dir = GCSPRINTF("%s/qemu-root-%d",
>> +                                      libxl__run_dir_path(),
>> guest_domid);
>> +        int r;
>> +
>>          flexarray_append(dm_args, "-xen-domid-restrict");
>>
>> +        /*
>> +         * Run QEMU in a chroot at XEN_RUN_DIR/qemu-root-%d
> 
> Maybe '<domid>' in the comment rather than '%d'?

Maybe. :-)

>> +         *
>> +         * There is no library function to do the equivalent of `rm
>> +         * -rf`.  However deprivileged QEMU in theory shouldn't be
>> +         * able to write any files, as the chroot would be owned by
>> +         * root, but it would be running as an unprivileged process.
>> +         * So in theory, old chroots should always be empty.
> 
> How does logging work if QEMU can't write to the chroot? I assume we are relying on stderr? Does using syslog still work?

Everything QEMU needs access to (including vnc sockets, qmp sockets, &c)
must either be opened before the chroot happens, or passed to QEMU as an
fd via qmp.  In the case of logging, this happens through stderr; but if
you search for 'chroot' in the design document you'll get a couple of
examples of different issues that need to be addressed (including
inserting a cd-rom and dealing with migration).

 -George


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel