All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Namjae Jeon" <namjae.jeon@samsung.com>
To: "'Al Viro'" <viro@zeniv.linux.org.uk>
Cc: <linux-fsdevel@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-cifs@vger.kernel.org>,
	<linux-cifsd-devel@lists.sourceforge.net>, <smfrench@gmail.com>,
	<senozhatsky@chromium.org>, <hyc.lee@gmail.com>, <hch@lst.de>,
	<hch@infradead.org>, <ronniesahlberg@gmail.com>,
	<aurelien.aptel@gmail.com>, <aaptel@suse.com>,
	<sandeen@sandeen.net>, <dan.carpenter@oracle.com>,
	<colin.king@canonical.com>, <rdunlap@infradead.org>,
	"'Sergey Senozhatsky'" <sergey.senozhatsky@gmail.com>,
	"'Steve French'" <stfrench@microsoft.com>
Subject: RE: [PATCH 3/5] cifsd: add file operations
Date: Tue, 23 Mar 2021 09:12:16 +0900	[thread overview]
Message-ID: <00ad01d71f79$2e9883d0$8bc98b70$@samsung.com> (raw)
In-Reply-To: <YFg/W4q9PHwTAJtZ@zeniv-ca.linux.org.uk>

> On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> > This adds file operations and buffer pool for cifsd.
> 
> Some random notes:
> 
> > +static void rollback_path_modification(char *filename) {
> > +	if (filename) {
> > +		filename--;
> > +		*filename = '/';
> What an odd way to spell filename[-1] = '/';...
Okay. Will fix.
> 
> > +int ksmbd_vfs_inode_permission(struct dentry *dentry, int acc_mode,
> > +bool delete) {
> 
> > +	if (delete) {
> > +		struct dentry *parent;
> > +
> > +		parent = dget_parent(dentry);
> > +		if (!parent)
> > +			return -EINVAL;
> > +
> > +		if (inode_permission(&init_user_ns, d_inode(parent), MAY_EXEC | MAY_WRITE)) {
> > +			dput(parent);
> > +			return -EACCES;
> > +		}
> > +		dput(parent);
> 
> Who's to guarantee that parent is stable?  IOW, by the time of that
> inode_permission() call dentry might very well not be a child of that thing...
Okay, Will fix.
> 
> > +	parent = dget_parent(dentry);
> > +	if (!parent)
> > +		return 0;
> > +
> > +	if (!inode_permission(&init_user_ns, d_inode(parent), MAY_EXEC | MAY_WRITE))
> > +		*daccess |= FILE_DELETE_LE;
> 
> Ditto.
Okay.
> 
> > +int ksmbd_vfs_mkdir(struct ksmbd_work *work,
> > +		    const char *name,
> > +		    umode_t mode)
> 
> 
> > +	err = vfs_mkdir(&init_user_ns, d_inode(path.dentry), dentry, mode);
> > +	if (!err) {
> > +		ksmbd_vfs_inherit_owner(work, d_inode(path.dentry),
> > +			d_inode(dentry));
> 
> ->mkdir() might very well return success, with dentry left unhashed negative.
> Look at the callers of vfs_mkdir() to see how it should be handled.
Okay, Will fix.
> 
> > +static int check_lock_range(struct file *filp,
> > +			    loff_t start,
> > +			    loff_t end,
> > +			    unsigned char type)
> > +{
> > +	struct file_lock *flock;
> > +	struct file_lock_context *ctx = file_inode(filp)->i_flctx;
> > +	int error = 0;
> > +
> > +	if (!ctx || list_empty_careful(&ctx->flc_posix))
> > +		return 0;
> > +
> > +	spin_lock(&ctx->flc_lock);
> > +	list_for_each_entry(flock, &ctx->flc_posix, fl_list) {
> > +		/* check conflict locks */
> > +		if (flock->fl_end >= start && end >= flock->fl_start) {
> > +			if (flock->fl_type == F_RDLCK) {
> > +				if (type == WRITE) {
> > +					ksmbd_err("not allow write by shared lock\n");
> > +					error = 1;
> > +					goto out;
> > +				}
> > +			} else if (flock->fl_type == F_WRLCK) {
> > +				/* check owner in lock */
> > +				if (flock->fl_file != filp) {
> > +					error = 1;
> > +					ksmbd_err("not allow rw access by exclusive lock from other
> opens\n");
> > +					goto out;
> > +				}
> > +			}
> > +		}
> > +	}
> > +out:
> > +	spin_unlock(&ctx->flc_lock);
> > +	return error;
> > +}
> 
> WTF is that doing in smbd?
This code was added to pass the smb2 lock test of samba's smbtorture.
Will fix it.
> 
> > +	filp = fp->filp;
> > +	inode = d_inode(filp->f_path.dentry);
> 
> That should be file_inode().  Try it on overlayfs, watch it do interesting things...
Okay.
> 
> > +	nbytes = kernel_read(filp, rbuf, count, pos);
> > +	if (nbytes < 0) {
> > +		name = d_path(&filp->f_path, namebuf, sizeof(namebuf));
> > +		if (IS_ERR(name))
> > +			name = "(error)";
> > +		ksmbd_err("smb read failed for (%s), err = %zd\n",
> > +				name, nbytes);
> 
> Do you really want the full pathname here?  For (presumably) spew into syslog?
No, Will fix.
> 
> > +int ksmbd_vfs_remove_file(struct ksmbd_work *work, char *name) {
> > +	struct path parent;
> > +	struct dentry *dir, *dentry;
> > +	char *last;
> > +	int err = -ENOENT;
> > +
> > +	last = extract_last_component(name);
> > +	if (!last)
> > +		return -ENOENT;
> 
> Yeccchhh...
I guess I change it err instead of -ENOENT.

> 
> > +	if (ksmbd_override_fsids(work))
> > +		return -ENOMEM;
> > +
> > +	err = kern_path(name, LOOKUP_FOLLOW | LOOKUP_DIRECTORY, &parent);
> > +	if (err) {
> > +		ksmbd_debug(VFS, "can't get %s, err %d\n", name, err);
> > +		ksmbd_revert_fsids(work);
> > +		rollback_path_modification(last);
> > +		return err;
> > +	}
> > +
> > +	dir = parent.dentry;
> > +	if (!d_inode(dir))
> > +		goto out;
> 
> Really?  When does that happen?
Will fix.
> 
> > +static int __ksmbd_vfs_rename(struct ksmbd_work *work,
> > +			      struct dentry *src_dent_parent,
> > +			      struct dentry *src_dent,
> > +			      struct dentry *dst_dent_parent,
> > +			      struct dentry *trap_dent,
> > +			      char *dst_name)
> > +{
> > +	struct dentry *dst_dent;
> > +	int err;
> > +
> > +	spin_lock(&src_dent->d_lock);
> > +	list_for_each_entry(dst_dent, &src_dent->d_subdirs, d_child) {
> > +		struct ksmbd_file *child_fp;
> > +
> > +		if (d_really_is_negative(dst_dent))
> > +			continue;
> > +
> > +		child_fp = ksmbd_lookup_fd_inode(d_inode(dst_dent));
> > +		if (child_fp) {
> > +			spin_unlock(&src_dent->d_lock);
> > +			ksmbd_debug(VFS, "Forbid rename, sub file/dir is in use\n");
> > +			return -EACCES;
> > +		}
> > +	}
> > +	spin_unlock(&src_dent->d_lock);
> 
> Hard NAK right there.  That thing has no business poking at that level.
> And I'm pretty certain that it's racy as hell.
Okay. It was same reason(smbtorture test), will fix it also.

Thanks for your review!


  reply	other threads:[~2021-03-23  0:13 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20210322052203epcas1p21fe2d04c4df5396c466c38f4d57d8bb8@epcas1p2.samsung.com>
2021-03-22  5:13 ` [PATCH 0/5] cifsd: introduce new SMB3 kernel server Namjae Jeon
2021-03-22  5:13   ` [PATCH 1/5] cifsd: add server handler and tranport layers Namjae Jeon
2021-03-22 22:18     ` Matthew Wilcox
2021-03-23  3:01       ` Namjae Jeon
2021-03-23  3:12         ` Matthew Wilcox
2021-03-23  3:16           ` Namjae Jeon
2021-03-22  5:13   ` [PATCH 2/5] cifsd: add server-side procedures for SMB3 Namjae Jeon
2021-03-22  6:47     ` Dan Carpenter
2021-03-22  6:50       ` Christoph Hellwig
2021-03-22 13:25         ` [Linux-cifsd-devel] " Stefan Metzmacher
2021-03-22 23:20         ` Namjae Jeon
2021-03-22 23:17       ` Namjae Jeon
2021-03-23  7:19         ` Dan Carpenter
2021-03-25  5:25           ` Sebastian Gottschall
2021-03-22  8:34     ` Matthew Wilcox
2021-03-22 10:27       ` Sergey Senozhatsky
2021-03-22 13:12         ` Matthew Wilcox
2021-03-22  5:13   ` [PATCH 3/5] cifsd: add file operations Namjae Jeon
2021-03-22  6:55     ` Al Viro
2021-03-23  0:12       ` Namjae Jeon [this message]
2021-03-22  7:02     ` Al Viro
2021-03-22  9:26       ` Sergey Senozhatsky
2021-03-22  7:04     ` Dan Carpenter
2021-03-22  9:39       ` Sergey Senozhatsky
2021-03-22  8:15     ` Matthew Wilcox
2021-03-22  9:03       ` Sergey Senozhatsky
2021-03-22 13:02         ` Matthew Wilcox
2021-03-22 13:57         ` Christoph Hellwig
2021-03-22 14:40           ` Matthew Wilcox
2021-03-22 17:09         ` Matthew Wilcox
2021-03-23  0:05           ` Sergey Senozhatsky
2021-03-22 16:16     ` Schaufler, Casey
2021-03-23  0:21       ` Namjae Jeon
2021-03-22  5:13   ` [PATCH 4/5] cifsd: add Kconfig and Makefile Namjae Jeon
2021-03-22  5:13   ` [PATCH 5/5] MAINTAINERS: add cifsd kernel server Namjae Jeon

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='00ad01d71f79$2e9883d0$8bc98b70$@samsung.com' \
    --to=namjae.jeon@samsung.com \
    --cc=aaptel@suse.com \
    --cc=aurelien.aptel@gmail.com \
    --cc=colin.king@canonical.com \
    --cc=dan.carpenter@oracle.com \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=hyc.lee@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-cifsd-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=ronniesahlberg@gmail.com \
    --cc=sandeen@sandeen.net \
    --cc=senozhatsky@chromium.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=smfrench@gmail.com \
    --cc=stfrench@microsoft.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.