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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan

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