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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

> 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.

Jan

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