Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1060241 - RFE: btrfs rootfs snapshots should be placed outside the mounted path
Summary: RFE: btrfs rootfs snapshots should be placed outside the mounted path
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Packaging Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-31 14:50 UTC by Neal Becker
Modified: 2015-06-29 14:54 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-29 14:54:32 UTC


Attachments (Terms of Use)
dirty hack to snapshot outside the FS (deleted)
2015-06-01 21:05 UTC, Konstantin Svist
no flags Details | Diff

Description Neal Becker 2014-01-31 14:50:52 UTC
Description of problem:

Problem is with yum-plugin-fs-snapshot

As discussed here:

http://permalink.gmane.org/gmane.linux.redhat.fedora.general/442138

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Chris Murphy 2014-02-18 18:13:55 UTC
The problem:
yum-plugin-fs-snapshot places snapshots within the parent subvolume, and therefore makes any (old) vulnerable or exploitable binaries available.

This is probably less of a concern for /boot and /home.


This thread on the Fedora Security list discusses this problem and some possible solutions:
https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html



Possible solutions:
- Place rootfs related snapshot(s) in a "snapshots" subvolume located at the top level of the btrfs file system. Because the top level of a Fedora installer created Btrfs file system isn't mounted by default (instead, selective subvolumes are mounted) the old snapshots aren't locatable.

- Also my making it a subvolume, yum-plugin-fs-snapshot can mount it on demand with nosuid or noexec mount option, place snapshots there, and umount it. Or this "snapshots" subvolume could be persistently mounted somewhere if these mount options are sufficient mitigation of the problem.

- Possibly SELinux can play a role here, although to be effective it'd have to somehow "layer" a new context over all contents of the "snapshots" subvolume without changing their labels, because we may want or need to boot those snapshots for a rollback.

Comment 2 Fedora End Of Life 2015-05-29 10:45:34 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Konstantin Svist 2015-06-01 21:05:54 UTC
Created attachment 1033514 [details]
dirty hack to snapshot outside the FS

I'd like to add my vote for this feature
In fact, I have hacked my fs-snapshot code to do this on my machine already (though it won't survive updates from the repo)

My setup: single btrfs partition (sda2; sda1 is BIOS boot partition). The btrfs FS has a subvolume "main" which is my main system.
Fs-snapshot is hacked to read its own config, check for extra_btrfs_volumes and snapshot them.

fs-snapshot.conf:
...
exclude = / /mnt
extra_btrfs_volumes = /dev/sda2|/main
...

Here, /dev/sda2 is the extra device to snapshot, and /main is the subvolume to snapshot.
The target will be named just like the previous yum snapshots, but located next to /main, not inside

Comment 4 Chris Murphy 2015-06-01 22:03:34 UTC
With yum being deprecated, and also bug 1044982 suggests this plugin isn't being ported to dnf, I'm uncertain of this bug's validity anymore. Maybe the way forward is to get snapper to support putting snapshots out of the normally mounted fs tree?

Comment 5 Konstantin Svist 2015-06-01 22:29:31 UTC
I'm pretty sure comment #9 says it's implemented in "snapper" plugin, whatever that is

I suppose nobody will use YUM [in some distant future], unless there had been any long term support releases :)

Comment 6 Fedora End Of Life 2015-06-29 14:54:32 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.