btrfs: Allow non-admin users to snapshot and restore their own subvolumes

[silverhadch]

A desktop user should be able to snapshot and restore their own home directory subvolume without needing sudo, doas, run0, or full admin rights.

The idea is:

• User owns their /home/$USER subvolume

• Snapm enforces scope: user can only act on their subvolume and snapshots

• No privilege escalation for system-wide volumes

This enables safe self-service rollback from a future GUI while keeping system integrity intact.

CC: @Conan-Kudo

[bmr-cymru]

This is interesting - thanks for bringing it up. We'll likely retain the current hard requirement for root privileges at least to begin with for the btrfs plugin, but this gives us something concrete to think about - if you are only using and snapshotting your own volumes then there's no in-principal reason I know of that this can't work. It's just a matter of implementation and plumbing (as a very quick first thought this may be easiest to achieve if we are behind an RPC interface, most likely DBus but there are other options being explored - we don't have a timeline for this work yet, but it is under active investigation).

[Conan-Kudo]

One thing to consider is that the interface would potentially be integrated into the Dolphin file manager, so you might want to develop some kind of system service and session service that is delegated from the system service, and Dolphin talks to it through D-Bus or some other RPC interface.

[bmr-cymru]

That's roughly in line with what I was thinking - it would honestly be kinda nice if Btrfs handled the privilege delegation for us (I wonder if there is any interest in having /bin/btrfs be SETUID/capabilities enabled - doubtful, I guess, but it would make our lives easier).

The other option is to pivot to a DBus model, although alternatives like Capn'n Proto actually suit some of our RPC needs better for things like application coordination (but afaik it lacks the security model that's baked into DBus).

This would potentially increase our resource needs for the project quite a bit, so it is going to need careful thinking and design, but it's good to have the issues filed and somewhere to at least discuss the options and figure out what we can reasonably take on.

[Conan-Kudo]

Well, it might be worth asking for feedback about this with the btrfs developers too. Maybe send an email to their mailing list? I don't know if they really have the appetite for this, but there are potentially other solutions (like making it so privileged operations are matched to the owner level instead of always requiring root regardless of who owns the data).

[emanuc]

That's roughly in line with what I was thinking - it would honestly be kinda nice if Btrfs handled the privilege delegation for us (I wonder if there is any interest in having /bin/btrfs be SETUID/capabilities enabled - doubtful, I guess, but it would make our lives easier).

The other option is to pivot to a DBus model, although alternatives like Capn'n Proto actually suit some of our RPC needs better for things like application coordination (but afaik it lacks the security model that's baked into DBus).

This would potentially increase our resource needs for the project quite a bit, so it is going to need careful thinking and design, but it's good to have the issues filed and somewhere to at least discuss the options and figure out what we can reasonably take on.

I know there is a proposed patch that has not been merged yet. Is this the correct functionality for the use case in question?

• unprivileged btrfs subvol list kdave/btrfs-progs#893
• Some user-permission changes to btrfs-progs kdave/btrfs-progs#762

If I’m not missing anything, the only thing missing is subvol list.
As a user, I can create subvolumes and snapshots, but I cannot delete them unless I use the mount option user_subvol_rm_allowed [1].

emanu@fedora ~> btrfs subvolume create test
Create subvolume './test'

emanu@fedora ~ [1]> btrfs subvolume snapshot -r test test_snap_user
Create readonly snapshot of 'test' in 'test_snap_user'

emanu@fedora ~> btrfs subvolume delete test_snap_user
Delete subvolume 342 (no-commit): '/home/emanu/test_snap_user'
ERROR: Could not destroy subvolume/snapshot: Operation not permitted
WARNING: deletion failed with EPERM, you don't have permissions or send may be in progress or the subvolume is set as default

emanu@fedora ~ [1]> sudo btrfs subvolume delete -i 343 /
Delete subvolume 343 (no-commit): '//home/emanu/test_snap_user'

emanu@fedora ~> ls -al test/
totale 0
drwxr-xr-x  1 emanu emanu    0 15 gen 22.29 ./
drwx--x---+ 1 emanu emanu 2024 15 gen 22.30 ../

emanu@fedora ~> ls -al test_snap_user/
totale 0
drwxr-xr-x  1 emanu emanu    0 15 gen 22.29 ./
drwx--x---+ 1 emanu emanu 2024 15 gen 22.30 ../

[1]

user_subvol_rm_allowed

(default: off)

Allow subvolumes to be deleted by their respective owner. Otherwise, only the root user can do that.

Note

Historically, any user could create a snapshot even if he was not owner of the source subvolume, the subvolume deletion 

has been restricted for that reason. The subvolume creation has been restricted but this mount option is still required. This is a usability issue. Since 4.18, the rmdir(2) syscall can delete an empty subvolume just like an ordinary directory. Whether this is possible can be detected at runtime, see rmdir_subvol feature in FILESYSTEM FEATURES.

[bmr-cymru]

That's roughly in line with what I was thinking - it would honestly be kinda nice if Btrfs handled the privilege delegation for us (I wonder if there is any interest in having /bin/btrfs be SETUID/capabilities enabled - doubtful, I guess, but it would make our lives easier).
The other option is to pivot to a DBus model, although alternatives like Capn'n Proto actually suit some of our RPC needs better for things like application coordination (but afaik it lacks the security model that's baked into DBus).
This would potentially increase our resource needs for the project quite a bit, so it is going to need careful thinking and design, but it's good to have the issues filed and somewhere to at least discuss the options and figure out what we can reasonably take on.

I know there is a proposed patch that has not been merged yet. Is this the correct functionality for the use case in question?

* [unprivileged `btrfs subvol list` kdave/btrfs-progs#893](https://github.com/kdave/btrfs-progs/pull/893)

* [Some user-permission changes to btrfs-progs kdave/btrfs-progs#762](https://github.com/kdave/btrfs-progs/pull/762)

@emanuc Oh, this is really interesting, thank you! It's late here right now, but I will look into this properly in the morning and see what we might be able to do with this - appreciate the links & all the detail!