Re: [Xen-devel] [PATCH RFC 06/12] libxl: set correct permissions for the full backend path

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-09-26 at 11:30 +0200, Roger Pau Monnà wrote:
> On 26/09/13 11:24, Ian Campbell wrote:
> > On Thu, 2013-09-26 at 11:20 +0200, Roger Pau Monnà wrote:
> >> On 25/09/13 17:18, Ian Campbell wrote:
> >>> On Wed, 2013-09-25 at 17:10 +0200, Roger Pau Monnà wrote:
> >>>> On 25/09/13 17:00, Ian Campbell wrote:
> >>>>> On Wed, 2013-09-25 at 16:02 +0200, Roger Pau Monnà wrote:
> >>>>>> On 25/09/13 15:57, Ian Campbell wrote:
> >>>>>>> On Mon, 2013-09-23 at 12:30 +0200, Roger Pau Monne wrote:
> >>>>>>>> The backend path should be fully owned by the domain where it 
> >>>>>>>> resides.
> >>>>>>>
> >>>>>>> I can see why /local/domain/<domid>backends/<type>/<id> would need to 
> >>>>>>> be
> >>>>>>> owned by the backend dom, but why
> >>>>>>> do /local/domain/<domid>backends/<type>/, 
> >>>>>>> /local/domain/<domid>backends/, etc need to be?
> >>>>>>
> >>>>>> The path /local/domain/<domid>backends/<type>/<guest_domid>/<id> is
> >>>>>> already owned by the driver domain, the problem is that if the driver
> >>>>>> domain has to perform the clean up of this path it should be able to
> >>>>>> fully remove it, otherwise we are leaving empty directories around in
> >>>>>> xenstore (backend/<type>/<guest_domid> and so).
> >>>>>>
> >>>>>> And performing the clean up from the toolstack domain is not that easy,
> >>>>>> we will have to add a way to signal the toolstack domain that the 
> >>>>>> driver
> >>>>>> domain has finished the disconnection and the directory can be cleaned.
> >>>>>
> >>>>> Don't we need that anyway so that the toolstack domain can synchronise
> >>>>> the end of the asynchronous op which is the remove?
> >>>>
> >>>> Not really IMHO, the toolstack waits for the device frontend to
> >>>> disconnect and then it removes the frontend xenstore entries. Then (or
> >>>> in parallel) the domain that's handling the backend should deal with the
> >>>> disconnection of the backend and perform any necessary actions and clean
> >>>> up the backend xenstore entries.
> >>>
> >>> So e.g. xl destroy can potentially return while the backend is still
> >>> closing down? That would mean it might fail to reboot the guest, because
> >>> the block device in the driver domain is still busy.
> >>
> >> True, since we don't synchronize with the toolstack there's a small
> >> window were a new domain could be created before the driver domain
> >> hasn't finished unplugging. This is a problem already with current udev
> >> implementation, but I think we can solve this by adding a watch in the
> >> toolstack that waits for the backend path to be destroyed (when the
> >> backend is on a driver domain, of course).
> >>
> >> I will expand this patch to include the above mentioned check.
> > 
> > Please do.
> > 
> > Can you also enumerate the intended permissions for each bit
> > of /local/domain/<domid>/backends/<type>/<guest_domid>/<id>
> > 
> > I think you are changing the perms of "backends" onwards, but is that
> > really necessary? The backend should be cleaning up <id>, which needs
> > write perms for <guest_domid> but could the toolstack not do the rest?
> 
> Yes, since I'm going to change the patch to syncronize with the
> toolstack domain, it can do the rest of the cleaning on behalf of the
> guest (the guest will only remove
> /local/domain/<domid>/backends/<type>/<guest_domid>/<id> and there won't
> be a need to change any permissions).

Excellent!


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel