linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <christian.brauner@ubuntu.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Miklos Szeredi <miklos@szeredi.hu>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: fsnotify path hooks
Date: Tue, 20 Apr 2021 13:41:54 +0200	[thread overview]
Message-ID: <20210420114154.mwjj7reyntzjkvnw@wittgenstein> (raw)
In-Reply-To: <CAOQ4uxi-BG9-XLmQ0uLp0vb_woF=M0EUasLDJG-zHd66PFuKGw@mail.gmail.com>

On Tue, Apr 20, 2021 at 09:01:09AM +0300, Amir Goldstein wrote:
> > One thing, whatever you end up passing to vfs_create() please make sure
> > to retrieve mnt_userns once so permission checking and object creation
> > line-up:
> >
> > int vfs_create(struct vfsmount *mnt, struct inode *dir,
> >                struct dentry *dentry, umode_t mode, bool want_excl)
> > {
> >         struct user_namespace *mnt_userns;
> >
> >         mnt_userns = mnt_user_ns(mnt);
> >
> >         int error = may_create(mnt_userns, dir, dentry);
> >         if (error)
> >                 return error;
> >
> >         if (!dir->i_op->create)
> >                 return -EACCES; /* shouldn't it be ENOSYS? */
> >         mode &= S_IALLUGO;
> >         mode |= S_IFREG;
> >         error = security_inode_create(dir, dentry, mode);
> >         if (error)
> >                 return error;
> >         error = dir->i_op->create(mnt_userns, dir, dentry, mode, want_excl);
> >         if (!error)
> >                 fsnotify_create(mnt, dir, dentry);
> >         return error;
> > }
> >
> 
> Christian,
> 
> What is the concern here?
> Can mnt_user_ns() change under us?
> I am asking because Al doesn't like both mnt_userns AND path to
> be passed to do_tuncate() => notify_change()
> So I will need to retrieve mnt_userns again inside notify_change()
> after it had been used for security checks in do_open().
> Would that be acceptable to you?

The mnt_userns can't change once a mnt has been idmapped and it can
never change if the mount is visible in the filesystem already. The only
case we've been worried about and why we did it this way is when you
have a caller do fd = open_tree(OPEN_TREE_CLONE) and then share that
unattached fd with multiple processes
T1: mkdirat(fd, "dir1", 0755);
T2: mount_setattr(fd, "",); /* changes idmapping */
That case isn't a problem if the mnt_userns is only retrieved once for
permission checking and operating on the inode. I think with your
changes that still shouldn't be an issue though since the vfs_*()
helpers encompass the permission checking anyway and for notify_change,
we could simply add a mnt_userns field to struct iattr and pass it down.

  reply	other threads:[~2021-04-20 11:42 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-28 15:56 [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask Amir Goldstein
2021-03-30  7:31 ` Christian Brauner
2021-03-30  9:31   ` Amir Goldstein
2021-03-30 16:24     ` Amir Goldstein
2021-03-31 10:08       ` Christian Brauner
2021-03-31 10:57         ` Amir Goldstein
2021-04-08 11:44         ` open_by_handle_at() in userns Amir Goldstein
2021-04-08 12:55           ` Christian Brauner
2021-04-08 14:15             ` J. Bruce Fields
2021-04-08 15:54               ` Amir Goldstein
2021-04-08 16:08                 ` J. Bruce Fields
2021-04-08 16:48                   ` Frank Filz
2021-04-08 15:34             ` Amir Goldstein
2021-04-08 15:41               ` Christian Brauner
2021-03-30 12:12 ` [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask Christian Brauner
2021-03-30 12:33   ` Amir Goldstein
2021-03-30 12:53     ` Christian Brauner
2021-03-30 12:55       ` Christian Brauner
2021-03-30 13:54       ` Amir Goldstein
2021-03-30 14:17         ` Christian Brauner
2021-03-30 14:56           ` Amir Goldstein
2021-03-31  9:46             ` Christian Brauner
2021-03-31 11:29               ` Amir Goldstein
2021-03-31 12:17                 ` Christian Brauner
2021-03-31 12:59                   ` Amir Goldstein
2021-03-31 12:54                 ` Jan Kara
2021-03-31 14:06                   ` Amir Goldstein
2021-03-31 20:59                     ` fsnotify path hooks Amir Goldstein
2021-04-01 10:29                       ` Jan Kara
2021-04-01 14:18                         ` Amir Goldstein
2021-04-02  8:20                           ` Amir Goldstein
2021-04-04 10:27                             ` LSM and setxattr helpers Amir Goldstein
2021-04-05 12:23                               ` Christian Brauner
2021-04-05 14:47                               ` Mimi Zohar
2021-04-06 15:43                                 ` Amir Goldstein
2021-04-05 16:18                               ` Casey Schaufler
2021-04-06  8:35                           ` fsnotify path hooks Jan Kara
2021-04-06 18:49                           ` Amir Goldstein
2021-04-08 12:52                             ` Jan Kara
2021-04-08 15:11                               ` Amir Goldstein
2021-04-09 10:08                                 ` Jan Kara
2021-04-09 10:45                                   ` Christian Brauner
2021-04-20  6:01                                     ` Amir Goldstein
2021-04-20 11:41                                       ` Christian Brauner [this message]
2021-04-20 11:58                                         ` Amir Goldstein
2021-04-20 13:38                                         ` Christian Brauner
2021-04-09 13:22                                   ` Amir Goldstein
2021-04-09 14:30                                     ` Al Viro
2021-04-09 14:39                                       ` Christian Brauner
2021-04-09 14:46                                         ` Al Viro
2021-04-09 15:20                                           ` Christian Brauner
2021-04-09 16:06                                       ` Amir Goldstein
2021-04-09 16:09                                         ` Amir Goldstein
2021-04-18 18:51                                   ` Amir Goldstein
2021-04-19  8:08                                     ` Amir Goldstein
2021-04-19 16:41                                 ` Amir Goldstein
2021-04-19 17:02                                   ` Al Viro
2021-04-19 22:04                                     ` Amir Goldstein
2021-04-20  7:53                                       ` Amir Goldstein
2021-03-31 13:06                 ` [RFC][PATCH] fanotify: allow setting FAN_CREATE in mount mark mask J. Bruce Fields
2021-03-30 12:20 ` Amir Goldstein

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=20210420114154.mwjj7reyntzjkvnw@wittgenstein \
    --to=christian.brauner@ubuntu.com \
    --cc=amir73il@gmail.com \
    --cc=bfields@fieldses.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --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 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).