Re: s6 init-stage1

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Tue, 6 Jan 2015 06:27:57 -0800

On Tue, Jan 6, 2015 at 4:02 AM, Laurent Bercot <ska-supervision_at_skarnet.org>
wrote:
>
> I very much dislike having / read-write. In desktops or other systems
> where /etc is not really static, it is unfortunately unavoidable
> (unless symlinks to /var are made, for instance /etc/resolv.conf should
> be a symlink to /var/etc/resolv.conf or something, but you cannot store,
> for instance, /etc/passwd on /var...)
>

What if /etc were a mount overlay? I don't know if other *nix systems
support the concept, but under Linux, mounting a file system onto an
existing directory simply "blocks" the original directory contents
"underneath", exposing only the file system "on top", and all writes go to
the "top" filesystem. This would allow you to cook up a minimalist /etc
that could be left read-only, but when the system comes up, /etc is
remounted as read-write with a different filesystem to capture read-write
data. Dismounting /etc would occur along with all the other dismounts at
the tail-end of shutdown. The only issue I could see is /etc/passwd having
a password set for root, which would be needed to secure the console in the
event that the startup failed somehow and /etc isn't mounted yet. This
implies a possible de-sync between the read-only /etc/passwd and the
read-write /etc/passwd; the former is fixed in stone, the later can change.

 But on servers and embedded systems, / should definitely be read-only.
> Having it read-write makes it susceptible to filesystem corruption,
> which kills the guarantee that your machine will boot to at least a
> debuggable state. A read-only / saves you the hassle of having a
> recovery system.
>

Interesting concept.
Received on Tue Jan 06 2015 - 14:27:57 UTC