Drawing lessons from fatal SELinux bug #1054350

[Chris Murphy]

On Jan 25, 2014, at 9:41 AM, Kevin Kofler <kevin.kofler at chello.at> wrote:

> Chris Murphy wrote:
>> If there is a directory that contains update and non-update related file
>> changes, that's a problem. If there's segmentation, then this can be done.
>> 
>> Clearly /home needs to be separate (it's OK to take a snapshot but just
>> don't use it by default in a rollback) or we lose changes in /home in a
>> rollback from the time of the snapshot to the time of the decision to
>> rollback.
>> 
>> Another possible case it's /etc/ where the either a package or the user
>> could make changes during the update.
> 
> There's also /root, and then the most annoying case: /var. /var/lib/rpm 
> definitely needs to be rolled back, but you DON'T want to roll back things 
> such as log files in /var/log or systemwide databases (other than the RPM 
> database).

Well it might be woefully ignorant for me to say, and seem like flamebaiting, but the mixing of such domains tells me that the FHS needs revision even outside of the context of snapshots. It's just that snapshots makes it more obvious the organization is deficient.

Another weird one for me is /var/lib/libvirt/images which I certainly wouldn't want to snapshot (more specifically I wouldn't want to rollback by default in the face of a bad update).

Another way of dealing with this is many more subvolumes so that they can be selectively snapshotted for rollbacks while others remain persistent. Again it's fine to snapshot them at the same time also, but the rollback behavior by default would only rollback the software updates.

For point of comparison, when choosing the default Btrfs layout opensuse's installer creates three partitions: swap, root (btrfs), home (btrfs). And creates the following subvolumes on root:

boot/grub2/x86_64-efi
home
opt
srv
tmp
usr/local
var/crash
var/log
var/opt
var/spool
var/tmp

There's more snapshot granularity available with this setup.

Chris Murphy