linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@libero.it>
To: Kai Krakow <hurikhan77@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: A user cannot remove his readonly snapshots?!
Date: Sat, 16 Sep 2017 11:04:13 +0200	[thread overview]
Message-ID: <2d343791-7b32-bd53-a03d-a5b26465d358@libero.it> (raw)
In-Reply-To: <20170916012248.0870f72d@jupiter.sol.kaishome.de>

On 09/16/2017 01:22 AM, Kai Krakow wrote:
> Am Sat, 16 Sep 2017 00:02:01 +0200
> schrieb Ulli Horlacher <framstag@rus.uni-stuttgart.de>:
> 
>> On Fri 2017-09-15 (23:44), Ulli Horlacher wrote:
[...]
> 
> 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.

"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

  parent reply	other threads:[~2017-09-16  9:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-15 16:37 A user cannot remove his readonly snapshots?! Ulli Horlacher
2017-09-15 17:08 ` Austin S. Hemmelgarn
2017-09-15 19:32   ` Ulli Horlacher
2017-09-18 11:36     ` Austin S. Hemmelgarn
2017-09-15 21:07 ` Peter Grandi
2017-09-15 21:44   ` Ulli Horlacher
2017-09-15 22:02     ` Ulli Horlacher
2017-09-15 23:22       ` Kai Krakow
2017-09-16  7:36         ` Ulli Horlacher
2017-09-16 11:29           ` Kai Krakow
2017-09-16  9:04         ` Goffredo Baroncelli [this message]
2017-09-16  9:22           ` Ulli Horlacher
2017-09-16  9:16       ` Peter Grandi
2017-09-16  8:10 ` Goffredo Baroncelli
2017-09-16  8:54   ` Ulli Horlacher
2017-09-16 10:19   ` Ulli Horlacher
2017-09-16 10:43     ` Marat Khalili
2017-09-16 11:47       ` Kai Krakow
2017-09-16 14:28         ` Ulli Horlacher
2017-09-18 11:39           ` Austin S. Hemmelgarn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2d343791-7b32-bd53-a03d-a5b26465d358@libero.it \
    --to=kreijack@libero.it \
    --cc=hurikhan77@gmail.com \
    --cc=kreijack@inwind.it \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).