From: Omar Sandoval <osandov-nWWhXC5lh1RBDgjK7y7TUQ@public.gmane.org>
To: Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
Cc: Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
linux-fsdevel
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
kernel-team <kernel-team-b10kYP2dOMg@public.gmane.org>,
Xi Wang <xi-GmWTxIRN22iJaUV4rX00uodd74u8MsAO@public.gmane.org>,
Omar Sandoval <osandov-b10kYP2dOMg@public.gmane.org>
Subject: Re: [RFC PATCH v2 1/2] fs: add AT_REPLACE flag for linkat() which replaces the target
Date: Tue, 21 Mar 2017 11:44:01 -0700 [thread overview]
Message-ID: <20170321184401.GA32507@vader> (raw)
In-Reply-To: <CA+55aFxpzYqt3MYe8Yd7PVVQoPkVpae5diYYBJXh0zu4JCJrYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Mar 21, 2017 at 09:30:30AM -0700, Linus Torvalds wrote:
> On Tue, Mar 21, 2017 at 7:51 AM, Omar Sandoval <osandov-nWWhXC5lh1RBDgjK7y7TUQ@public.gmane.org> wrote:
> > */
> > -int vfs_link(struct dentry *old_dentry, struct inode *dir, struct dentry *new_dentry, struct inode **delegated_inode)
> > +int vfs_link(struct dentry *old_dentry, struct inode *dir,
> > + struct dentry *new_dentry, struct inode **delegated_inode,
> > + unsigned int flags)
> > {
> > struct inode *inode = old_dentry->d_inode;
> > + struct inode *target = new_dentry->d_inode;
> > unsigned max_links = dir->i_sb->s_max_links;
> > int error;
> >
> > if (!inode)
> > return -ENOENT;
> >
> > - error = may_create(dir, new_dentry);
> > + if (target) {
> > + if (flags & AT_REPLACE)
> > + error = may_delete(dir, new_dentry, d_is_dir(old_dentry));
> > + else
> > + error = -EEXIST;
> > + } else {
> > + error = may_create(dir, new_dentry);
> > + }
Hi, Linus,
Thanks for taking a look.
> This looks bogus.
>
> In particular, that "may_delete()" cannot be right. It should still
> *also* have the right to create something in that directory.
>
> But even if you replace it with checks for both deletion _and_
> creation, it won't be right, since the test for d_is_negative() on the
> target in may_delete() looks wrong for this situation.
>
> Normally, you cannot delete a negative entry (think of what that would
> do in a overlay situation), but it should still be ok to link a
> positive entry on top of a negative one.
This is actually the exact same check we have in vfs_rename():
----
if (!target) {
error = may_create(new_dir, new_dentry);
} else {
new_is_dir = d_is_dir(new_dentry);
if (!(flags & RENAME_EXCHANGE))
error = may_delete(new_dir, new_dentry, is_dir);
else
error = may_delete(new_dir, new_dentry, new_is_dir);
}
----
I tried to keep the same semantics as rename().
> Also, I think the above is incorrect for yet another case: moving
> somethign on top of a directory should be disallowed. We do later on
> check that the *source* isn't a directory (since you can't link
> directories), but I'm not seeing where you'd be checking that you
> don't move over a directory either.
That check is happening in may_delete():
----
if (isdir) {
if (!d_is_dir(victim))
return -ENOTDIR;
if (IS_ROOT(victim))
return -EBUSY;
} else if (d_is_dir(victim))
return -EISDIR;
----
> So I don't think this patch is acceptable as such. I also suspect that
> it should be done in multiple phases.
>
> Linus
WARNING: multiple messages have this Message-ID (diff)
From: Omar Sandoval <osandov@osandov.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
kernel-team <kernel-team@fb.com>, Xi Wang <xi@cs.washington.edu>,
Omar Sandoval <osandov@fb.com>
Subject: Re: [RFC PATCH v2 1/2] fs: add AT_REPLACE flag for linkat() which replaces the target
Date: Tue, 21 Mar 2017 11:44:01 -0700 [thread overview]
Message-ID: <20170321184401.GA32507@vader> (raw)
In-Reply-To: <CA+55aFxpzYqt3MYe8Yd7PVVQoPkVpae5diYYBJXh0zu4JCJrYA@mail.gmail.com>
On Tue, Mar 21, 2017 at 09:30:30AM -0700, Linus Torvalds wrote:
> On Tue, Mar 21, 2017 at 7:51 AM, Omar Sandoval <osandov@osandov.com> wrote:
> > */
> > -int vfs_link(struct dentry *old_dentry, struct inode *dir, struct dentry *new_dentry, struct inode **delegated_inode)
> > +int vfs_link(struct dentry *old_dentry, struct inode *dir,
> > + struct dentry *new_dentry, struct inode **delegated_inode,
> > + unsigned int flags)
> > {
> > struct inode *inode = old_dentry->d_inode;
> > + struct inode *target = new_dentry->d_inode;
> > unsigned max_links = dir->i_sb->s_max_links;
> > int error;
> >
> > if (!inode)
> > return -ENOENT;
> >
> > - error = may_create(dir, new_dentry);
> > + if (target) {
> > + if (flags & AT_REPLACE)
> > + error = may_delete(dir, new_dentry, d_is_dir(old_dentry));
> > + else
> > + error = -EEXIST;
> > + } else {
> > + error = may_create(dir, new_dentry);
> > + }
Hi, Linus,
Thanks for taking a look.
> This looks bogus.
>
> In particular, that "may_delete()" cannot be right. It should still
> *also* have the right to create something in that directory.
>
> But even if you replace it with checks for both deletion _and_
> creation, it won't be right, since the test for d_is_negative() on the
> target in may_delete() looks wrong for this situation.
>
> Normally, you cannot delete a negative entry (think of what that would
> do in a overlay situation), but it should still be ok to link a
> positive entry on top of a negative one.
This is actually the exact same check we have in vfs_rename():
----
if (!target) {
error = may_create(new_dir, new_dentry);
} else {
new_is_dir = d_is_dir(new_dentry);
if (!(flags & RENAME_EXCHANGE))
error = may_delete(new_dir, new_dentry, is_dir);
else
error = may_delete(new_dir, new_dentry, new_is_dir);
}
----
I tried to keep the same semantics as rename().
> Also, I think the above is incorrect for yet another case: moving
> somethign on top of a directory should be disallowed. We do later on
> check that the *source* isn't a directory (since you can't link
> directories), but I'm not seeing where you'd be checking that you
> don't move over a directory either.
That check is happening in may_delete():
----
if (isdir) {
if (!d_is_dir(victim))
return -ENOTDIR;
if (IS_ROOT(victim))
return -EBUSY;
} else if (d_is_dir(victim))
return -EISDIR;
----
> So I don't think this patch is acceptable as such. I also suspect that
> it should be done in multiple phases.
>
> Linus
next prev parent reply other threads:[~2017-03-21 18:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-21 14:51 [RFC PATCH v2 0/2] fs: add AT_REPLACE flag for linkat() Omar Sandoval
2017-03-21 14:51 ` Omar Sandoval
[not found] ` <cover.1490103963.git.osandov-b10kYP2dOMg@public.gmane.org>
2017-03-21 14:51 ` [RFC PATCH v2 1/2] fs: add AT_REPLACE flag for linkat() which replaces the target Omar Sandoval
2017-03-21 14:51 ` Omar Sandoval
2017-03-21 16:30 ` Linus Torvalds
[not found] ` <CA+55aFxpzYqt3MYe8Yd7PVVQoPkVpae5diYYBJXh0zu4JCJrYA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-03-21 18:44 ` Omar Sandoval [this message]
2017-03-21 18:44 ` Omar Sandoval
2017-03-21 19:02 ` Linus Torvalds
2017-03-21 19:02 ` Linus Torvalds
2017-03-21 20:37 ` Miklos Szeredi
2017-03-21 21:06 ` Linus Torvalds
2017-03-21 14:51 ` [RFC PATCH v2 2/2] Btrfs: add support for linkat() AT_REPLACE Omar Sandoval
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=20170321184401.GA32507@vader \
--to=osandov-nwwhxc5lh1rbdgjk7y7tuq@public.gmane.org \
--cc=kernel-team-b10kYP2dOMg@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=osandov-b10kYP2dOMg@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
--cc=xi-GmWTxIRN22iJaUV4rX00uodd74u8MsAO@public.gmane.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 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.