Re: [PATCH v4 09/12] tools/xenstored: Use priv_domid for manual nodes and permission

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-07-25 03:24, Jürgen Groß wrote:
> On 25.07.25 04:28, Jason Andryuk wrote:
> > Usually, priv_domid == dom0_domid == 0, and that is what is expected.
> > If we rename s/dom0_domid/store_domid/, it seems more likely we want to
> > actually have the priv_domid as the owner.
> Yes, I agree.
>
> > That leads to follow on changes to ensure that the priv_domid is created
> > first.
> >
> > Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx>
> > ---
> > Will this blow up if priv_domid doesn't exist?
> That won't be a problem. The problematic case will be when priv_domid is
> never changed due to no doamin having the CONTROL cap, and some random
> other domU happens to have domid 0.
>
> So maybe priv_domid should be initialized statically to e.g. DOMID_IDLE,
> as with your init_domains() loop a "normal" dom0 will always have the
> CONTROL cap and thus will result in priv_domid being set.
There is existing use of DOMID_INVALID, so I'll use that

> Same applies probably to store_domid, but that should be set to priv_domid
> after init_domains() in case no domain had the XENSTORE cap.
>
> If both aren't detected it should be fine to bail out early.
For our use cases, we want the possibility to run xenstored without a 
control domain.  In that case, I think it would make sense to set 
priv_domid = store_domid to get xenstored to run.
> > Maybe it would be better to just create these as store_domid.
> No, reasoning see above. And xenstore-stubdom accesses to Xenstore nodes
> via the "normal" interfaces shouldn't need any special privileges.
>
> Reviewed-by: Juergen Gross <jgross@xxxxxxxx>
Thanks, but I held off applying with the priv_domid = store_domid 
assignment.  (Well dom0_domid since it's before the rename).
Regards,
Jason