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

From: Juergen Gross <jgross@suse.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: xen-devel@lists.xenproject.org,
	Ian Jackson <ian.jackson@eu.citrix.com>, Wei Liu <wl@xen.org>
Subject: Re: [Xen-devel] [RFC PATCH 4/5] tools: add xenfs tool
Date: Wed, 11 Sep 2019 13:34:09 +0200	[thread overview]
Message-ID: <21bad2b6-8487-a59c-71b3-aedf475e5170@suse.com> (raw)
In-Reply-To: <a00f9b2a-1a2d-145f-daaf-6cd8cc4d3f25@suse.com>

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

Juergen

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