On Tue, Jan 6, 2015 at 4:02 AM, Laurent Bercot <[email protected]> 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.
