Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

[Goffredo Baroncelli <kreijack@libero.it>]

On 03/12/2014 08:31 PM, Chris Murphy wrote:
> 
> On Mar 12, 2014, at 1:12 PM, Goffredo Baroncelli <kreijack@inwind.it> wrote:
> 
[...]
>>
>> I am working to prototype something like that. A "mount.btrfs" command which
>> 1) handles the rollback (i.e. the user make a snapshot which is a rollback; if something goes wrong and the machine reboot before ending the process, during the subvolume mounting phase the rollback replaces the "original" subvolume)
>>
>> 2) handles the automount (i.e. if a subvolume has the right xattr it is automatically mounted in the right place)
>>
>> My idea is that the subvolume are grouped so:
>>
>> @<name>				simple subvolume
>> @<name>.<timestamp>		snapshot of subvolume <name>
>> @<name>.rollback		rollback subvolume
>>
>> If @<name>.rollback exists, then it replace @<name> (something went wrong, the machine rebooted so the rollback have to take place of the original subvolume)
>>
>> For each @<name> subvolume the following xattrs are considered:
>> user.btrfs.automount=1|0	the subvolume has to be automounted
>> user.btrfs.mntpoint=<path>	subvolume mount point
>>
>>
>> So this "mount.btrsf" command should:
>>
>> 1) mount the root btrfs filesystem (subvolid=5) in a temporary directory
>> 2) performing the auto rollback (this behaviour can be controlled by another xattr)
>> 3) mount the subvolume "@" as "root" (like the default one) in the right mount point
>> 4) for each subvolume which has user.btrfs.automount=1, it should be mounted under the path stored in the "user.btrfs.mntpoint" xattr (relative to "@" or absolute)
>> 5) umount the btrfs filesystem mounted at #1, or better move it to a new position in order
>> to allow managing (snapshot) of the different subvolumes.
>>
>> Thoughts ?
> 
> In effect this obviates boot parameter rootflags=subvol= since the
> file system metadata self-describe the subvol to be mounted,
> correct?
Definetely; 
> 
> Your suggestion also sounds like it places snapshots outside of their
> parent subvolume? 
yes, to me snapshot and "parent subvolume" are sibling more than parent/child. This simplify the rollback scenario. For example using the convention above we can rollback all the subvolumes mounting all the snapshots where the timestamp is less than the desired value.

> If so it mitigates a possible security concern if
> the snapshot contains (old) binaries with vulnerabilities. I asked
> about how to go about assessing this on the Fedora security list: 
> https://lists.fedoraproject.org/pipermail/security/2014-February/001748.html
>
> There aren't many replies but the consensus is that it's a legitimate
> concern, so either the snapshots shouldn't be persistently available
> (which is typical with e.g. snapper, and also
> yum-plugin-fs-snapshot), and/or when the subvolume containing
> snapshots is mounted, it's done with either mount option noexec or
> nosuid (no consensus on which one, although Gnome Shell uses nosuid
> by default when automounting removable media). 

Interesting observation
> 
> 
> Chris Murphy
> 
> 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5