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
Received on Tue Jun 21 2016 - 15:02:42 UTC