All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Sage Weil <sage@newdream.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/6] Btrfs commit fixes, async subvol operations
Date: Mon, 25 Oct 2010 15:58:42 -0400	[thread overview]
Message-ID: <20101025195842.GI18818@think> (raw)
In-Reply-To: <Pine.LNX.4.64.1010251239080.7660@cobra.newdream.net>

On Mon, Oct 25, 2010 at 12:41:46PM -0700, Sage Weil wrote:
> On Mon, 25 Oct 2010, Chris Mason wrote:
> > These all look good to me and I'm pulling them in.
> 
> Great, thanks!
> 
> > > The last item is a change to SNAP_DESTROY to allow deletion of a 
> > > snapshot when the user owns the subvol's root inode and the parent 
> > > directory permissions are such that we would have allowed an rmdir(2).  
> > > Goffredo Baroncelli posted a similar patch that replicates the rmdir(2) 
> > > semantics completely (except for the empty directory check) by 
> > > duplicating some VFS code.  Whether we want weaker semantics, duplicated 
> > > code, or some new EXPORT_SYMBOLS is up to you I think.  Note that this 
> > > is distinct from a similar patch (also from Goffredo) that allows 
> > > rmdir(2) to remove an empty subvol; my goal is to allow a non-empty 
> > > subvol to be deleted by a non-root user.  As long as I can do that, my 
> > > daemon doesn't have to run as root and I'm a happy camper.  :)
> > 
> > Someone at the storage workshop mentioned that this subvol deletion
> > trick is slightly stronger than rm -rf, to make it include the same
> > level of permission checks would require testing all the directories in
> > the tree for permissions.
> 
> I think that was me :)

Grin, two different people then ;)

>  
> > For now, could you please make a mount -o user_subvol_rm_allowed option?
> > (or something similar with a better name).
> 
> Sure.  
> 
> Do you have a preference as far as what checks are implemented?  My patch 
> implemented a simplified approximation of may_rmdir(); Goffredo's 
> duplicated the vfs checks.  I guess I'm leaning toward the latter...

Yes, lets duplicate the vfs checks.  Christoph just sat bolt upright in
whatever ski lift he's currently riding.

We should also make sure they do the subvol rm against the root of the
subvol (if that check isn't already done), none of the magic to resolve
the subvol based on any file inside it.  I don't want people to
accidentally think they are deleting a subdir and have it go higher up
into the directory tree.

Oh, and it shouldn't work on the root of the FS either ;)

-chris

  reply	other threads:[~2010-10-25 19:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-25 19:07 [PATCH 0/6] Btrfs commit fixes, async subvol operations Sage Weil
2010-10-25 19:07 ` [PATCH 1/6] Btrfs: fix deadlock in btrfs_commit_transaction Sage Weil
2010-10-25 19:07   ` [PATCH 2/6] Btrfs: async transaction commit Sage Weil
2010-10-25 19:07     ` [PATCH 3/6] Btrfs: add START_SYNC, WAIT_SYNC ioctls Sage Weil
2010-10-25 19:07       ` [PATCH 4/6] Btrfs: add SNAP_CREATE_ASYNC ioctl Sage Weil
2010-10-25 19:07         ` [PATCH 5/6] Btrfs: make SNAP_DESTROY async Sage Weil
2010-10-25 19:07           ` [PATCH 6/6] Btrfs: allow subvol deletion by owner Sage Weil
2010-10-26  6:46   ` [PATCH 1/6] Btrfs: fix deadlock in btrfs_commit_transaction liubo
2010-10-26 16:36     ` Sage Weil
2010-10-26 17:06       ` Chris Mason
2010-10-27  0:41         ` liubo
2010-10-25 19:29 ` [PATCH 0/6] Btrfs commit fixes, async subvol operations Chris Mason
2010-10-25 19:41   ` Sage Weil
2010-10-25 19:58     ` Chris Mason [this message]
2010-10-25 21:27       ` Sage Weil

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=20101025195842.GI18818@think \
    --to=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=sage@newdream.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.