user_subvol_rm_allowed vs rmdir_subvol

user_subvol_rm_allowed vs rmdir_subvol

[Chris Murphy]

Came across this podman issue yesterday
https://github.com/containers/libpod/issues/3963


Question 1: For unprivileged use case, is it intentional that the user
creates a subvolume/snapshot using 'btrfs sub create' and that the
user delete it with 'rm -rf' ?

And is the consequence of this performance? Because I see rm -rf must
individually remove all files and dirs from the subvolume first,
before rmdir() is called to remove the subvolume. Where as 'btrfs sub
del' calls BTRFS_IOC_SNAP_DESTROY ioctl which is pretty much
immediate, with cleanup happening in the background.


Question 2:

As it relates to the podman issue, what do Btrfs developers recommend?
If kernel > 4.18, and if unprivileged, then use 'rm -rf' to delete
subvolumes? Otherwise use 'btrfs sub del' with root privilege?


Question 3:
man 5 btrfs has a confusing note for user_subvol_rm_allowed mount option:

               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.

2nd sentence "subvolume creation has been restricted"  I can't parse
that. Is it an error, or can it be worded differently?


-- 
Chris Murphy

RE: user_subvol_rm_allowed vs rmdir_subvol

[misono.tomohiro]

Hello,

(It seems that you already have answers but anyway...)

> Came across this podman issue yesterday
> https://github.com/containers/libpod/issues/3963
> 
> 
> Question 1: For unprivileged use case, is it intentional that the user creates a subvolume/snapshot using 'btrfs sub
> create' and that the user delete it with 'rm -rf' ?

Yes. The problem with "btrfs sub delete" is that the permission check is only performed to the top directory(subvolume).
Terefore unless user_subvol_rm_allowed mount option is used, "bttrfs sub delete" command is restricted for unprivileged user.

> 
> And is the consequence of this performance? Because I see rm -rf must individually remove all files and dirs from the
> subvolume first, before rmdir() is called to remove the subvolume. Where as 'btrfs sub del' calls BTRFS_IOC_SNAP_DESTROY
> ioctl which is pretty much immediate, with cleanup happening in the background.

Yes.

> 
> 
> Question 2:
> 
> As it relates to the podman issue, what do Btrfs developers recommend?
> If kernel > 4.18, and if unprivileged, then use 'rm -rf' to delete subvolumes? Otherwise use 'btrfs sub del' with root
> privilege?

- "btrfs sub delete" if mounted with subvol_rm_allowed
- "rm -r" if not mounted with subvol_rm_allowed
 
> Question 3:
> man 5 btrfs has a confusing note for user_subvol_rm_allowed mount option:
> 
>                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.
> 
> 2nd sentence "subvolume creation has been restricted"  I can't parse that. Is it an error, or can it be worded differently?

You cannot create a snapshot of a subvolume which is owned by other user now (apparently old btrfs allowed this).

In summary, subvolume deletion by unprivileged user is restricted by default because:
 1. a user could create a snapshot which was not owned by the user in old btrfs.
 2. BTRFS_IOC_SNAP_DESTROY ioctl only performs permission check to the top directory.

I think 1 is not a problem anymore, byt 2 still remains. 

Thanks.

Re: user_subvol_rm_allowed vs rmdir_subvol

[Chris Murphy]

Super. Thanks for the reply!

On Tue, Sep 10, 2019 at 3:29 AM misono.tomohiro@fujitsu.com
<misono.tomohiro@fujitsu.com> wrote:
>
> Hello,
>
> (It seems that you already have answers but anyway...)
>
> > Came across this podman issue yesterday
> > https://github.com/containers/libpod/issues/3963
> >
> >
> > Question 1: For unprivileged use case, is it intentional that the user creates a subvolume/snapshot using 'btrfs sub
> > create' and that the user delete it with 'rm -rf' ?
>
> Yes. The problem with "btrfs sub delete" is that the permission check is only performed to the top directory(subvolume).
> Terefore unless user_subvol_rm_allowed mount option is used, "bttrfs sub delete" command is restricted for unprivileged user.
>
> >
> > And is the consequence of this performance? Because I see rm -rf must individually remove all files and dirs from the
> > subvolume first, before rmdir() is called to remove the subvolume. Where as 'btrfs sub del' calls BTRFS_IOC_SNAP_DESTROY
> > ioctl which is pretty much immediate, with cleanup happening in the background.
>
> Yes.
>
> >
> >
> > Question 2:
> >
> > As it relates to the podman issue, what do Btrfs developers recommend?
> > If kernel > 4.18, and if unprivileged, then use 'rm -rf' to delete subvolumes? Otherwise use 'btrfs sub del' with root
> > privilege?
>
> - "btrfs sub delete" if mounted with subvol_rm_allowed
> - "rm -r" if not mounted with subvol_rm_allowed
>
> > Question 3:
> > man 5 btrfs has a confusing note for user_subvol_rm_allowed mount option:
> >
> >                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.
> >
> > 2nd sentence "subvolume creation has been restricted"  I can't parse that. Is it an error, or can it be worded differently?
>
> You cannot create a snapshot of a subvolume which is owned by other user now (apparently old btrfs allowed this).
>
> In summary, subvolume deletion by unprivileged user is restricted by default because:
>  1. a user could create a snapshot which was not owned by the user in old btrfs.
>  2. BTRFS_IOC_SNAP_DESTROY ioctl only performs permission check to the top directory.
>
> I think 1 is not a problem anymore, byt 2 still remains.
>
> Thanks.



-- 
Chris Murphy