Re: Support for merged-/usr now in debootstrap; default for stretch?
On Wed, Sep 14, 2016 at 05:08:18PM +0200, Michael Biebl wrote:
> Am 14.09.2016 um 16:50 schrieb Pierre Chifflier:
> > Except that breaks having different mount points, which is useful to
> > enforce different mount options (my /usr is nodev,ro).
> > Does this mean this cannot be supported anymore ? It would be a step
> > backward, security-speaking, if split /usr does not work at all.
>
> That's still possible, it would be an improvement even, as now all of
> your system would be in /usr and would be confined by your mount
> options. Atm you have parts in / and parts in /usr and your mount
> options only apply to the bits in /usr.
> A fully read-only system is actually much simpler with the merged-usr setup.
I think it would be worthwhile to split up and move parts of /var as well.
It is a big mess of distinct stuff:
* parts of packaging: /var/lib/dpkg (especially info/) or files generated at
install/reconfigure time. These could probably be stored under /usr as
they are modified at the same time.
* user data: /var/www, /var/lib/mysql, /var/mail
* volatile not-for-backup cache: /var/cache
* stuff that would be in /var/cache if not for some detail:
/var/lib/apt/lists (not in /var/cache only because non-root has no way to
recover from deletion)
* temporary scratch space (not in /tmp so others can't mess with it)
* various state, both system and user
* managed config files
* logs
The current split comes from '80s use cases, when /usr was meant to be
mounted over network to enable sharing between machines as files there took
entire MEGABYTES of space. Thus, the split became:
* /bin, /sbin and co: needed to mount the rest
* /usr: shareable over the net
* /var: not easily shareable (deduplication and CoW wasn't invented yet)
None of this makes sense anymore. Even smallest ARMs you can install Debian
on without heavy changes have since moved to multi-gigabyte storage, so if
you have local media at all (ie, not network boot), you can as well have
/usr together with the rest. And a decade ago, when Nokia tried tiny NAND
plus big eMMC, the /-vs-/usr split proved too hard to adapt for their use
case so they ended up with /usr on NAND that included lots of symlinks to
/opt.
And when sharing storage between machines, there's no need to micromanage
common files anymore -- just give every system its own logical filesystem
and use one of CoW/deduplication schemes.
So what are modern use cases?
* security: want ro for as much as possible
* backup retention: want to know what to exclude, what to store "just for
restore upon disk failure" and what to store long time
* snapshots
Current FHS makes the last part especially bad, and requires either lots of
symlinks or lots of waste. Generally, we want two separate areas of
snapshots:
* the system. Especially vital for unstable, but useful for any system you
might make changes to from time to time. Lets you roll back and forward
to any prior state, to recover from breakages, test experimental stuff,
etc.
* user data. In case you made a bad edit a week ago, etc. No real point
for wholesale rollback but unlike plain backups, having all of this as
greppable/etc files is handy.
Especially for system backups, you want them complete in one piece because
of interdependencies. Trying to mix /usr /etc and system parts of /var from
different points of time is likely to result in breakage. Yet if you roll
back the whole of /var you lose parts of user data stored there.
Meow!
--
Second "wet cat laying down on a powered-on box-less SoC on the desk" close
shave in a week. Protect your ARMs, folks!
Reply to: