Drawing lessons from fatal SELinux bug #1054350

[Tomasz Torcz]

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
> LVM.  

  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
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140125/7d49fc52/attachment.sig>