Couldn't one play with bind mounts to keep the absolute paths consistent on both sides of the pivot operation?
On Tue, Jun 21, 2016 at 10:02 AM Laurent Bercot <[email protected]> wrote: > On 21/06/2016 16:24, Martin "eto" Misuth wrote: > > Reinterpreting based on my personal experience, situation would be > basically > > similar to - "deleting" servicedirs from "underneath" running s6-svscan > one (I > > did that one to myself due to script error, don't ask): > > No, it's not the same thing. When you pivot_root, everything is kept > open, > the inodes do not change, everything keeps working - except that the > absolute paths to the files are not the same anymore. If you were referring > to a service as /service/foo beforehand, it has to be referred to as > /old_root_location/service/foo after a pivot_root. > > If you used absolute paths to link servicedirs into your scandir, and you > pivot_root, then s6-svscan will rightfully freak out on its next scan. But > s6-supervise should keep working - the control interface hasn't > disappeared, > it is just named differently. > > > > Would it be possible to somehow "posixly" lock control files in such > way, that > > remount/pivot_root/unlink would fail and one could not delete them > without force > > flag, indicating indeed sysadmin error? > > No. Well, there are "extended attributes" that allow you to do that kind > of > thing, but I'm not sure to what extent those are portable. But they > wouldn't > protect you against pivot_root anyway, because no files are deleted or > changed when you pivot_root, it's just a rotation in the directory tree. > (Also, trying to protect admins against themselves is doomed to fail, and > a sure recipe for bad design.) > > The only sensible "protection" against pivot_root is: do your pivot_root > very early when basically nothing is running, and start your supervision > tree later on. > > -- > Laurent > >
