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

[Juergen Gross <jgross@xxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel