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