On Jan 24, 2014, at 4:16 PM, Josh Stone <jist...@redhat.com> wrote: > On 01/24/2014 01:38 PM, Chris Murphy wrote: >> On Jan 24, 2014, at 2:58 AM, Sergio Pascual <sergio.pa...@gmail.com >>> There is a plugin yum-plugin-fs-snapshot, but it requires better >>> documentation and system integration. >> >> Well I'd go a step further and ask some more basic questions how how >> many snapshots should be bootable, whether systemd-journal should be >> persistent across snapshots or snapshot specific, what exactly are we >> snapshotting, can we require /home be separate (presently we don't >> require it) in order to support such bootable snapshots, on and on. > > I'd also ask where we keep these snapshots, and how do you prevent > access to them normally. IIRC, yum-plugin-fs-snapshot makes btrfs > snapshots as a subvolume directly within the filesystem, which means it > will still be accessible.
It's possible the utility could mount another subvolume not in the present path, including top level ID 5 (the first and default subvolume by mkfs.btrfs), and place snapshots there, and then unmount. For LVM thinp snapshots, they become completely out of tree LVs. They aren't accessible unless explicitly mounted. > This concerns me especially in the case of security updates -- for > example, a vulnerable setuid-root binary should be locked up tight! The organization question is valid. But sudo or root could just mount any subvolume. However, btrfs read-only snapshots can't be written to even by root. Naturally root could just create a rw snapshot of a ro snapshot and then delete the ro snapshot, but an audit probably ought to show the subvolume UUIDs and creation dates involved so that we'd know this is what happened. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
