Drawing lessons from fatal SELinux bug #1054350

Chris Murphy lists at colorremedies.com
Fri Jan 24 22:10:04 UTC 2014

On Jan 24, 2014, at 11:19 AM, Kevin Fenzi <kevin at scrye.com> wrote:

> On Fri, 24 Jan 2014 09:41:13 -0800
> Adam Williamson <awilliam at redhat.com> wrote:
>> AIUI there is/was a long-term plan to integrate this as core
>> functionality using btrfs snapshots - in fact that was one of the
>> major attractions of the idea of switching to btrfs-by-default in the
>> first place. I believe those involved didn't think the LVM-based
>> implementation was clean/robust enough to use by default, but a
>> btrfs-based implementation would be. Do correct me if I'm wrong.
> I don't think snapshots are a partcularly good solution, unless there's
> some way to only roll back the rpm/yum transaction without also rolling
> back unrelated changes. 

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. Btrfs allows per file snapshots with cp --reflink so there might be a way to carve the snapshot with a scalpel but I prefer doing it with subvolume granularity. Plus that granularity translates to LVM.

Chris Murphy

More information about the devel mailing list