All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: overlayfs <linux-unionfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 16/35] ovl: readd lsattr/chattr support
Date: Fri, 13 Apr 2018 17:48:56 +0300	[thread overview]
Message-ID: <CAOQ4uxjcB5_S15khi3yZ4MZcyQTHTup8ka-Oy_ts4bfHE1P8bw@mail.gmail.com> (raw)
In-Reply-To: <20180412150826.20988-17-mszeredi@redhat.com>

On Thu, Apr 12, 2018 at 6:08 PM, Miklos Szeredi <mszeredi@redhat.com> wrote:
> Implement FS_IOC_GETFLAGS and FS_IOC_SETFLAGS.
>
> Needs vfs_ioctl() exported to modules.
>
> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
> ---
>  fs/internal.h       |  1 -
>  fs/ioctl.c          |  1 +
>  fs/overlayfs/file.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/fs.h  |  2 ++
>  4 files changed, 62 insertions(+), 1 deletion(-)
>
> diff --git a/fs/internal.h b/fs/internal.h
> index 3319bf39e339..d5108d9c6a2f 100644
> --- a/fs/internal.h
> +++ b/fs/internal.h
> @@ -176,7 +176,6 @@ extern const struct dentry_operations ns_dentry_operations;
>   */
>  extern int do_vfs_ioctl(struct file *file, unsigned int fd, unsigned int cmd,
>                     unsigned long arg);
> -extern long vfs_ioctl(struct file *file, unsigned int cmd, unsigned long arg);
>
>  /*
>   * iomap support:
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 5ace7efb0d04..696f4c46a868 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -49,6 +49,7 @@ long vfs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>   out:
>         return error;
>  }
> +EXPORT_SYMBOL(vfs_ioctl);
>
>  static int ioctl_fibmap(struct file *filp, int __user *p)
>  {
> diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c
> index 05e3e2f80b89..cc004ff1b05b 100644
> --- a/fs/overlayfs/file.c
> +++ b/fs/overlayfs/file.c
> @@ -8,6 +8,7 @@
>
>  #include <linux/cred.h>
>  #include <linux/file.h>
> +#include <linux/mount.h>
>  #include <linux/xattr.h>
>  #include <linux/uio.h>
>  #include "overlayfs.h"
> @@ -291,6 +292,63 @@ long ovl_fallocate(struct file *file, int mode, loff_t offset, loff_t len)
>         return ret;
>  }
>
> +static long ovl_real_ioctl(struct file *file, unsigned int cmd,
> +                          unsigned long arg)
> +{
> +       struct fd real;
> +       const struct cred *old_cred;
> +       long ret;
> +
> +       ret = ovl_real_file(file, &real);
> +       if (ret)
> +               return ret;
> +
> +       old_cred = ovl_override_creds(file_inode(file)->i_sb);
> +       ret = vfs_ioctl(real.file, cmd, arg);
> +       revert_creds(old_cred);
> +
> +       fdput(real);
> +
> +       return ret;
> +}
> +
> +long ovl_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> +{
> +       long ret;
> +       struct inode *inode = file_inode(file);
> +
> +       switch (cmd) {
> +       case FS_IOC_GETFLAGS:
> +               ret = ovl_real_ioctl(file, cmd, arg);
> +               break;
> +
> +       case FS_IOC_SETFLAGS:
> +               if (!inode_owner_or_capable(inode))
> +                       return -EACCES;
> +
> +               ret = mnt_want_write_file(file);
> +               if (ret)
> +                       return ret;
> +
> +               ret = ovl_copy_up(file_dentry(file));
> +               if (!ret) {
> +                       ret = ovl_real_ioctl(file, cmd, arg);
> +
> +                       inode_lock(inode);
> +                       ovl_copyflags(ovl_inode_real(inode), inode);
> +                       inode_unlock(inode);
> +               }
> +
> +               mnt_drop_write_file(file);
> +               break;
> +
> +       default:
> +               ret = -ENOTTY;

I am wondering out loud.
This is a change of behavior that fs specific ioctls cannot be executed
on overlay file - arguably a good change of behavior, but still a change
that applications may got dependent on.

Would it have been better to opt-in for this change by a more generic
config/mount options, for example "consistent_fd" , instead of
"copy_up_shared" and then we can choose whether or not to
pass though unknown ioctls to real file.

I know we removed the want_write_file() protection from VFS, but
still, pass through of ioctls was the legacy behavior. Thoughts?
I don't mind to wait and see if someone shouts.

Thanks,
Amir.

  reply	other threads:[~2018-04-13 14:48 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 15:07 [RFC PATCH 00/35] overlayfs: stack file operations Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 01/35] vfs: clean up dedup Miklos Szeredi
2018-04-12 16:25   ` Matthew Wilcox
2018-04-12 17:24     ` Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 02/35] vfs: add path_open() Miklos Szeredi
2018-04-12 16:38   ` Matthew Wilcox
2018-04-12 15:07 ` [RFC PATCH 03/35] vfs: optionally don't account file in nr_files Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 04/35] ovl: copy up times Miklos Szeredi
2018-04-13  8:25   ` Amir Goldstein
2018-04-13 14:23   ` Vivek Goyal
2018-04-12 15:07 ` [RFC PATCH 05/35] ovl: copy up inode flags Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 06/35] Revert "Revert "ovl: get_write_access() in truncate"" Miklos Szeredi
2018-04-12 15:07 ` [RFC PATCH 07/35] ovl: copy up file size as well Miklos Szeredi
2018-04-24 18:10   ` Vivek Goyal
2018-04-12 15:07 ` [RFC PATCH 08/35] ovl: deal with overlay files in ovl_d_real() Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 09/35] ovl: stack file ops Miklos Szeredi
2018-04-26 14:13   ` Vivek Goyal
2018-04-26 14:43     ` Miklos Szeredi
2018-04-26 14:56       ` Vivek Goyal
2018-04-26 15:01         ` Miklos Szeredi
2018-04-26 15:13           ` Vivek Goyal
2018-04-26 15:21             ` Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 10/35] ovl: add helper to return real file Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 11/35] ovl: readd read_iter Miklos Szeredi
2018-04-13 13:35   ` Amir Goldstein
2018-04-12 15:08 ` [RFC PATCH 12/35] ovl: readd write_iter Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 13/35] ovl: readd fsync Miklos Szeredi
2018-04-23 13:36   ` Vivek Goyal
2018-04-23 13:39     ` Miklos Szeredi
2018-04-23 13:53       ` Vivek Goyal
2018-04-23 14:09         ` Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 14/35] ovl: readd mmap Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 15/35] ovl: readd fallocate Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 16/35] ovl: readd lsattr/chattr support Miklos Szeredi
2018-04-13 14:48   ` Amir Goldstein [this message]
2018-04-17 19:51   ` Amir Goldstein
2018-04-22  8:35     ` Amir Goldstein
2018-04-22 15:18       ` Amir Goldstein
2018-04-23 10:21       ` Miklos Szeredi
2018-04-23 10:28         ` Miklos Szeredi
2018-04-23  6:11   ` Ritesh Harjani
2018-04-12 15:08 ` [RFC PATCH 17/35] ovl: readd fiemap Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 18/35] ovl: readd O_DIRECT support Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 19/35] ovl: readd reflink/copyfile/dedup support Miklos Szeredi
2018-04-17 20:31   ` Amir Goldstein
2018-04-18  8:39     ` Amir Goldstein
2018-05-03 16:04     ` Miklos Szeredi
2018-05-03 19:48       ` Amir Goldstein
2018-04-12 15:08 ` [RFC PATCH 20/35] vfs: don't open real Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 21/35] vfs: add f_op->pre_mmap() Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 22/35] ovl: copy-up on MAP_SHARED Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 23/35] vfs: simplify dentry_open() Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 24/35] Revert "ovl: fix relatime for directories" Miklos Szeredi
2018-04-13 14:02   ` Amir Goldstein
2018-04-13 15:55   ` Vivek Goyal
2018-04-12 15:08 ` [RFC PATCH 25/35] Revert "vfs: update ovl inode before relatime check" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 26/35] Revert "ovl: fix may_write_real() for overlayfs directories" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 27/35] Revert "ovl: don't allow writing ioctl on lower layer" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 28/35] Revert "vfs: add flags to d_real()" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 29/35] Revert "vfs: do get_write_access() on upper layer of overlayfs" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 30/35] Revert "vfs: make argument of d_real_inode() const" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 31/35] Revert "vfs: add d_real_inode() helper" Miklos Szeredi
2018-04-18  8:19   ` Amir Goldstein
2018-04-18 11:42     ` Miklos Szeredi
2018-04-18 13:38       ` Steven Rostedt
2018-04-18 13:49         ` Miklos Szeredi
2018-04-18 13:56           ` Steven Rostedt
2018-04-19 19:54           ` Vivek Goyal
2018-04-20  9:14             ` Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 32/35] Partially revert "locks: fix file locking on overlayfs" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 33/35] Revert "fsnotify: support overlayfs" Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 34/35] vfs: simplify d_op->d_real() Miklos Szeredi
2018-04-12 15:08 ` [RFC PATCH 35/35] ovl: fix documentation of non-standard behavior Miklos Szeredi
2018-04-13 11:23   ` Amir Goldstein
2018-04-25 14:49 ` [RFC PATCH 00/35] overlayfs: stack file operations J. R. Okajima
2018-04-25 19:44   ` Miklos Szeredi
2018-05-04 15:23 ` Miklos Szeredi
2018-05-05 16:37   ` Amir Goldstein
2018-05-08 14:25     ` Miklos Szeredi

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=CAOQ4uxjcB5_S15khi3yZ4MZcyQTHTup8ka-Oy_ts4bfHE1P8bw@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=mszeredi@redhat.com \
    /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.