Drawing lessons from fatal SELinux bug #1054350
tomek at pipebreaker.pl
Sat Jan 25 16:46:09 UTC 2014
On Fri, Jan 24, 2014 at 03:10:04PM -0700, Chris Murphy wrote:
> 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
Note that this situation is perfectly handled by Offline Updates.
After reboot, there aren't collateral changes to filesystem, only upgrade-related
ones. So if there's a need for revert, the previous state is clearly defined.
Tomasz Torcz There exists no separation between gods and men:
xmpp: zdzichubg at chrome.pl one blends softly casual into the other.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
More information about the devel