Re: [Xen-devel] [RFC PATCH 4/5] tools: add xenfs tool

[Juergen Gross <jgross@suse.com>]

On 11.09.19 13:50, Jan Beulich wrote:
> On 11.09.2019 13:34, Juergen Gross wrote:
>> On 11.09.19 12:07, Jan Beulich wrote:
>>> On 11.09.2019 11:57, Juergen Gross wrote:
>>>> On 11.09.19 11:30, Jan Beulich wrote:
>>>>> On 11.09.2019 08:20, Juergen Gross wrote:
>>>>>> --- a/tools/misc/Makefile
>>>>>> +++ b/tools/misc/Makefile
>>>>>> @@ -24,6 +24,7 @@ INSTALL_SBIN-$(CONFIG_X86)     += xen-lowmemd
>>>>>>     INSTALL_SBIN-$(CONFIG_X86)     += xen-mfndump
>>>>>>     INSTALL_SBIN-$(CONFIG_X86)     += xen-ucode
>>>>>>     INSTALL_SBIN                   += xencov
>>>>>> +INSTALL_SBIN                   += xenfs
>>>>>
>>>>> Why SBIN? Is there anything wrong with allowing unprivileged
>>>>> users r/o access? Or is this because in order to access the
>>>>> hypercall interface one needs to be root? If so, we may want
>>>>> to consider relaxing/avoiding/bypassing this in some sensible
>>>>> way.
>>>>
>>>> Installing to bin is fine with me, but relaxing the root restriction
>>>> might be more difficult and/or questionable.
>>>>
>>>> I was thinking of "mounting" the xen-sysfs to either Xenstore or
>>>> the kernel's sysfs (probably the latter, as Xenstore in a stubdom
>>>> would need to enable access to xen-sysfs for that stubdom ,too).
>>>>
>>>> This would then enable accessing some or all entries from non-root.
>>>
>>> Right, going through the kernel's sysfs is what I too was
>>> considering (I don't think xenstore is appropriate for this).
>>> The main issue I'd see with this is the split brain permissions
>>> handling. I'd prefer for there to be just one party determining
>>> who is allowed to see what, but even if the hypervisor told the
>>> kernel, there would still be a dependency upon the kernel also
>>> respecting the request. While not much of a problem as long as
>>> all of this is Dom0-only, with DomU-s in mind this would need
>>> taking care of.
>>
>> Hmm, why? I think we agree that DomUs should get access only to either
>> global data (read-only) which doesn't do any harm,
> 
> I guess opinions tend to differ here: There may well be people
> thinking that certain things shouldn't be seen by everyone.

I didn't mean to give them access to all global data, but to selected
items only. This would be controlled by the hypervisor.

> 
>> or to data related
>> only to them (so per-domain data). Maybe driver-domains or device model
>> stubdoms would need access to data related to the domains they are
>> serving.
>>
>> Whether a domU lets a user access that data or not should only be
>> decided by the domU (applies to dom0, too).
> 
> Like above, there may be different views here as well.

But how should Xen make a choice for the guest here? The guest is
free to not give its users access to the data, but like data returned
via a hypercall Xen has absolutely no way to control whether the data
is accessible by a guest's user process or not.


Juergen

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