A user cannot remove his readonly snapshots?!

I have my btrfs filesystem mounted with option user_subvol_rm_allowed

tux@xerus: btrfs --version
btrfs-progs v4.4

tux@xerus: uname -a
Linux xerus 4.4.0-93-generic #116-Ubuntu SMP Fri Aug 11 21:17:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

tux@xerus: id
uid=1000(tux) gid=100(users) groups=100(users)

tux@xerus: btrfs subvolume snapshot -r /test/tux/zz /test/tux/zz/.snapshot/2017-09-15_1824.test tux@xerus: btrfs subvolume delete /test/tux/zz/.snapshot/2017-09-15_1824.test Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'
ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1824.test': Read-only file system

root can delete this snapshot, but not the user. Why?

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

Add 'user_subvol_rm' to the mount options and try again.

It's because of a poor decision made regarding permissions surrounding subvolume operations. The original argument was to prevent accidental data loss (stupid argument, rm -rf is just as bad and nearly as fast on most modern systems), and that behavior has never been changed. In fact, I'd advocate using that option on everything, because otherwise you have trivial resource exhaustion issues (users can create a resource they then can't remove). Ideally, normal users wouldn't be able to create or delete subvolumes unless explicitly allowed (possibly through delegation by ownership or something).

root@xerus:~# mount -vo user_subvol_rm /dev/sdd4 /test
mount: wrong fs type, bad option, bad superblock on /dev/sdd4,
       missing codepage or helper program, or other error

In some cases useful info is found in syslog - try dmesg | tail or so.

root@xerus:~# dmesg | tail -2
[1514588.018991] BTRFS info (device sdd4): unrecognized mount option 'user_subvol_rm'
[1514588.028430] BTRFS: open_ctree failed

user_subvol_rm is not listed on
https://btrfs.wiki.kernel.org/index.php/Mount_options

Did you mean user_subvol_rm_allowed?
I have already used this option, without success. See above.

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

Yes, that's what I meant, sorry about the confusion.

I missed that, sorry.

Ordinary permissions still apply both to 'create' and 'delete':

tree$ sudo mkdir /fs/sda7/dir
tree$ btrfs sub create /fs/sda7/dir/sub
ERROR: cannot access /fs/sda7/dir/sub: Permission denied

tree$ sudo chmod a+rwx /fs/sda7/dir
tree$ btrfs sub create /fs/sda7/dir/sub
Create subvolume '/fs/sda7/dir/sub'

tree$ btrfs sub delete /fs/sda7/dir/sub
Delete subvolume (no-commit): '/fs/sda7/dir/sub'
ERROR: cannot delete '/fs/sda7/dir/sub': Operation not permitted tree$ sudo mount -o remount,user_subvol_rm_allowed /fs/sda7 tree$ btrfs sub delete /fs/sda7/dir/sub
Delete subvolume (no-commit): '/fs/sda7/dir/sub'

tree$ btrfs sub create /fs/sda7/dir/sub
Create subvolume '/fs/sda7/dir/sub'

tree$ sudo chmod a-w /fs/sda7/dir
tree$ btrfs sub delete /fs/sda7/dir/sub
Delete subvolume (no-commit): '/fs/sda7/dir/sub'
ERROR: cannot delete '/fs/sda7/dir/sub': Permission denied

tree$ sudo chmod a+w /fs/sda7/dir
tree$ btrfs sub delete /fs/sda7/dir/sub Delete subvolume (no-commit): '/fs/sda7/dir/sub' tree$ sudo rmdir /fs/sda7/dir

My user tux is the owner of the snapshot directory, because he has created it!

tux@xerus:/test/tux/zz: id
uid=1000(tux) gid=100(users) groups=100(users)

tux@xerus:/test/tux/zz: ll .snapshot/

drwxr-xr-x  tux      users    - 2017-09-15 18:22:26 .snapshot/2017-09-15_1822.test
drwxr-xr-x  tux      users    - 2017-09-15 18:22:26 .snapshot/2017-09-15_1824.test
drwxr-xr-x  tux      users    - 2017-09-15 18:57:39 .snapshot/2017-09-15_1859.test

tux@xerus:/test/tux/zz: btrfs subvolume delete .snapshot/2017-09-15_1859.test Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1859.test'
ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only file system

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

I can delete normal subvolumes but not the readonly snapshots:

tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume create test Create subvolume './test'

tux@xerus:/test/tux/zz/.snapshot: ll

drwxr-xr-x  tux      users    - 2017-09-15 18:22:26 2017-09-15_1822.test
drwxr-xr-x  tux      users    - 2017-09-15 18:22:26 2017-09-15_1824.test
drwxr-xr-x  tux      users    - 2017-09-15 18:57:39 2017-09-15_1859.test
drwxr-xr-x  tux      users    - 2017-09-15 23:58:51 test

tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete test Delete subvolume (no-commit): '/test/tux/zz/.snapshot/test'

tux@xerus:/test/tux/zz/.snapshot: btrfs subvolume delete 2017-09-15_1859.test Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1859.test'
ERROR: cannot delete '/test/tux/zz/.snapshot/2017-09-15_1859.test': Read-only file system

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

Am Sat, 16 Sep 2017 00:02:01 +0200
schrieb Ulli Horlacher <[email protected]>:

See "man mount" in section btrfs mount options: There is a mount option to allow normal user to delete snapshots. But this is said to has security implication I cannot currently tell. Maybe someone else knows.

Regards,
Kai

Replies to list-only preferred.

As I wrote first: "I have mounted with option user_subvol_rm_allowed"

tux@xerus:/test/tux/zz/.snapshot: mount | grep /test
/dev/sdd4 on /test type btrfs (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

This does not help. A user cannot remove a readonly snapshot he just has created.

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

Am Sat, 16 Sep 2017 09:36:33 +0200
schrieb Ulli Horlacher <[email protected]>:

Yes, sorry, I only later discovered the other posts.

Regards,
Kai

Replies to list-only preferred.

[...]

"btrfs sub del" removes a subvolume independently by its contents: it doesn't check the subvolume files/directories and their permission/ownership.

This is different from a "rm -rf", which (e.g.) can't delete a directory owned by a different user with files

ghigo@venice:/tmp$ mkdir d
ghigo@venice:/tmp$ mkdir d/d
ghigo@venice:/tmp$ touch d/d/f
ghigo@venice:/tmp$ sudo chown nobody d/d
ghigo@venice:/tmp$ rm -rf d
rm: cannot remove 'd/d/f': Permission denied

In the past I proposed to allow an ordinary user to remove an *empty* subvolume with a simple rmdir (if he has the permissions). This would solve this kind of problem.

https://www.spinics.net/lists/linux-btrfs/msg06499.html

or to relax the check around "btrfs sub del", so an user can remove an _empty_ subvolume

https://www.spinics.net/lists/linux-btrfs/msg06522.html

BR
G.Baroncelli

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

This would help a lot!
Where can I sign this petition? :-)

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

[ ... ]

It is because of ordinary permissions for both subvolumes and snapshots:

tree$ btrfs sub create /fs/sda7/sub
Create subvolume '/fs/sda7/sub'

tree$ chmod a-w /fs/sda7/sub
tree$ btrfs sub del /fs/sda7/sub
Delete subvolume (no-commit): '/fs/sda7/sub'
ERROR: cannot delete '/fs/sda7/sub': Permission denied

tree$ chmod u+w /fs/sda7/sub
tree$ btrfs sub del /fs/sda7/sub
Delete subvolume (no-commit): '/fs/sda7/sub'

It is however possible to remove an ordinary read-only directory, *as long as its parent directory is not read-only too*:

  tree$  mkdir /fs/sda7/sub
  tree$  chmod a-w /fs/sda7/sub
  tree$  rmdir /fs/sda7/sub; echo $?

0

IIRC this came up before, and the reason for the difference is that a subvolume root directory is "special" because its '..' entry points to itself (inode 256), that is if it is read-only its parent directory (itself) then is read-only too.

You should change the "ro" property to false before deleting it

	btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false

BR
G.Baroncelli

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

tux@xerus: btrfs property set /test/tux/zz/.snapshot/2017-09-15_1824.test ro false tux@xerus: btrfs subvolume delete /test/tux/zz/.snapshot/2017-09-15_1824.test Delete subvolume (no-commit): '/test/tux/zz/.snapshot/2017-09-15_1824.test'

That's it! It works (now)! Great! Thanks!

Up to now I was thinking about a sudo solution, but this is not necessary any more. Less complex solutions are always better :-)

I *love* this mailing list :-)

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

Still one problem is left:
How can I test a subvolume for the mount option user_subvol_rm_allowed? df only works for the root subvolume:

root@xerus:/test/tux# df -T .
Filesystem     Type  1K-blocks   Used Available Use% Mounted on
/dev/sdd4      btrfs  54524928 103372  52326324   1% /test

root@xerus:/test/tux# df -T zz
Filesystem     Type 1K-blocks   Used Available Use% Mounted on
-              -     54524928 103372  52326324   1% /test/tux/zz

root@xerus:/test/tux# mount | grep /test
/dev/sdd4 on /test type btrfs (rw,relatime,space_cache,user_subvol_rm_allowed,subvolid=5,subvol=/)

How do I know the btrfs filesystem for a given subvolume? Do I really have to manually test the diretory path upwards?

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

It was discussed recently: the answer is, unfortunately, yes, until someone patches df to do it for us. You can do it more or less efficiently by analyzing /proc/mounts .

--

With Best Regards,
Marat Khalili

Am Sat, 16 Sep 2017 13:43:23 +0300
schrieb Marat Khalili <[email protected]>:

Or you do "btrfs device stats .", it shows the associated device(s). You can put any path instead of "." in the command.

Next, look at "lsblk <devicepath>".

The problem is that the root subvolume id may not be mounted anywhere, so /proc/mounts may not help.

On my system:

$ sudo btrfs device stats .
[/dev/bcache16].write_io_errs    0
[/dev/bcache16].read_io_errs     0
[/dev/bcache16].flush_io_errs    0
[/dev/bcache16].corruption_errs  0
[/dev/bcache16].generation_errs  0
[/dev/bcache48].write_io_errs    0
[/dev/bcache48].read_io_errs     0
[/dev/bcache48].flush_io_errs    0
[/dev/bcache48].corruption_errs  0
[/dev/bcache48].generation_errs  0
[/dev/bcache32].write_io_errs    0
[/dev/bcache32].read_io_errs     0
[/dev/bcache32].flush_io_errs    0
[/dev/bcache32].corruption_errs  0
[/dev/bcache32].generation_errs  0

$ lsblk /dev/bcache16
NAME     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
bcache16 254:16   0 925,5G  0 disk /mnt/btrfs-pool

Regards,
Kai

Replies to list-only preferred.

tux@xerus:/test/tux/zz: btrfs device stats .
ERROR: getting dev info for devstats failed: Operation not permitted

Not possible for a normal user.

Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: [email protected]
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/
REF:<[email protected]>

btrfs fi show should be possible for a normal user, and that also lists devices. Alternatively, you can check /sys/fs/btrfs and correlate UUID's (possibly easier programmatically than analyzing regular output).