Linux-BTRFS Archive on lore.kernel.org
 help / color / Atom feed
* user_subvol_rm_allowed vs rmdir_subvol
@ 2019-09-08 17:58 Chris Murphy
  2019-09-10  9:28 ` misono.tomohiro
  0 siblings, 1 reply; 3+ messages in thread
From: Chris Murphy @ 2019-09-08 17:58 UTC (permalink / raw)
  To: Btrfs BTRFS

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: user_subvol_rm_allowed vs rmdir_subvol
  2019-09-08 17:58 user_subvol_rm_allowed vs rmdir_subvol Chris Murphy
@ 2019-09-10  9:28 ` misono.tomohiro
  2019-09-10 16:32   ` Chris Murphy
  0 siblings, 1 reply; 3+ messages in thread
From: misono.tomohiro @ 2019-09-10  9:28 UTC (permalink / raw)
  To: Chris Murphy, Btrfs BTRFS

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: user_subvol_rm_allowed vs rmdir_subvol
  2019-09-10  9:28 ` misono.tomohiro
@ 2019-09-10 16:32   ` Chris Murphy
  0 siblings, 0 replies; 3+ messages in thread
From: Chris Murphy @ 2019-09-10 16:32 UTC (permalink / raw)
  To: misono.tomohiro; +Cc: Chris Murphy, Btrfs BTRFS

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-08 17:58 user_subvol_rm_allowed vs rmdir_subvol Chris Murphy
2019-09-10  9:28 ` misono.tomohiro
2019-09-10 16:32   ` Chris Murphy

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org linux-btrfs@archiver.kernel.org
	public-inbox-index linux-btrfs


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox