Request classic confinement and aliases for btrbk-ivo Snap

store-requests
1

Hi all,

I’ve snapped btrbk, a backup tool for btrfs subvolumes. The package is very simple, but needs classic confinement for the reasons below:

  • It’s a backup tool for btrfs subvolumes, capable of creating time-machine like directories anywhere on disk. It may be used to create backup of / , /var and any other subvolumes user has and, in general, those backup don’t belong on any user’s home folder, but on a specific designated directory somewhere else.

  • There’s a coupling between btrfs-progs (set of tools used to manage a btrfs filesystem) and kernel version (see here). Distributions usually ship package versions matching running kernel, so the Snap package doesn’t ship btrfs-progs, relying on system provided version. Since btrbk is completely dependent on btrfs-progs, I believe this is the safest approach.

Also, I’d like to request following aliases:

  • btrbk-ivo.btrk --> btrbk
  • btrbk-ivo.lsbtr --> lsbtr

Those are the names of main tools provided by this Snap.

Thanks

–
Ivo

2

How sensitive are btrfs-progs to kernel version? major.minor, major.minor.micro? It seems possible for you to ship btrfs-progs for the different versions you want to support, then parse uname -r and key off that on what to execute. That said, how do distros do this? (eg, Ubuntu ships a single btrfs-progs). Is it possible for you to ship the latest stable version that will work with all kernels of a particular version and earlier?

Also, it’s unclear why you need write access to everything and seems plausible that system-backup could be use to read and removable-media to write the backups. Is there something about btrbk or btrfs-progs that doesn’t work with this approach?

3

Let’s go:

  • I’d rather not assume responsibility for using an unsuitable version of btrfs-progs. Since this is a backup tool, dealing with people’s data (and possibly causing corruption, if a subvolume deletion goes wrong), I’m leaving to the user the task of providing a correct btrfs-progs version. As for how sensitive the tools are, regarding major, minor, etc., I’m unfortunately not sure. What I know is that btrfs is still in heavy development, and it’s safer (in my opinion) let the user decide what he wants to use.

  • btrbk can write it’s snapshots and backups anywhere (they’re different things in btrbk parlage). I, for instance, keep my snapshots in /snapshots and backups in a different machine, copied over ssh (btrbk does this automatically). If we follow this path - setting the Snap to strict confinement - we’d have the following “consequences”:

    • Snapshots/backup sources would have to be referenced through /var/lib/snapd/hostfs. This is more of an annoyance than a blocker, but still. Also, it would prevent the tool from writing the snapshots anywhere but user’s home dir (or removable-media, as you suggested). Doesn’t make much sense to have snapshots of /var, /home or even / in nobody’s home (even root), in my opinion.
    • I’d need to ship btrfs-progs (whatever version is needed) myself and, to be honest, I don’t want the burden. I’m taking the safe path of providing btrbk tool and only this. I’m not sure latest versions would be retro compatible with older kernels. Anyway, if someone is using btrfs, is using btrfs-progs also, so no need to bother with using different versions (again, my opinion).
    • btrbk can use some tools to optimize/adjust the process - stream compressors like gzip, zstd, pigz, etc., and buffer management tools as mbuffer and even ssh, to transfer backups to other machines over network. All of these are optional and some must be present on hosts and remote machines. Embedding all of these, including configuration of ssh, would add unnecessary complexity, since the package is intended to provide btrbk and btrbk only - in fact, besides the script (btrbk is written in Perl), I’m only embedding Perl itself, some configuration examples and shell completers. As I said, I’m not aiming at providing a “complete” environment for running btrbk, but just the tool.

Let me know if you need more info. Thanks for your time.

Ivo

4

Gentle ping? :slight_smile:

5

Hey @ivo.cavalcante,

So if you take a look at the Process for reviewing classic confinement snaps, this request does not fall under any of the supported categories to grant classic confinement. On the other side, I see that we could explore alternatives (like the the one suggested above) that even though they require more effort from your side, they could make this snap work under strict confinement, enjoying the benefits of a stable runtime environment meanwhile not granting unnecessary privileges. @pedronis do you have any further opinion on this?

6

@ivo.cavalcante ping, could you make any progress on keeping btrbk-ivo under strict confinement?

7

@ivo.cavalcante - since we’ve not heard back from you, we are removing this request from our review queue. When you have more time to respond, simply do so here and we can add the request back to the queue. Thanks