From: Jan Kara <jack@suse.cz>
To: Ted Tso <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH 1/2] ext4: Be more strict when verifying flags set via SETFLAGS ioctls
Date: Thu, 6 Oct 2016 12:35:48 +0200 [thread overview]
Message-ID: <20161006103548.GA31055@quack2.suse.cz> (raw)
In-Reply-To: <1475671375-22969-2-git-send-email-jack@suse.cz>
On Wed 05-10-16 14:42:54, Jan Kara wrote:
> Currently we just silently ignore flags that we don't understand (or
> that cannot be manipulated) through EXT4_IOC_SETFLAGS and
> EXT4_IOC_FSSETXATTR ioctls. This makes it problematic for the unused
> flags to be used in future (some app may be inadvertedly setting them
> and we won't notice until the flag gets used). Also this is inconsistent
> with other filesystems like XFS or BTRFS which return EOPNOTSUPP when
> they see a flag they cannot set.
>
> ext4 has the additional problem that there are flags which are returned
> by EXT4_IOC_GETFLAGS ioctl but which cannot be modified via
> EXT4_IOC_SETFLAGS. So we have to be careful to ignore value of these
> flags and not fail the ioctl when they are set (as e.g. chattr(1) passes
> flags returned from EXT4_IOC_GETFLAGS to EXT4_IOC_SETFLAGS without any
> masking and thus we'd break this utility).
>
> Signed-off-by: Jan Kara <jack@suse.cz>
I've found out this does not quite work because EXT4_FL_USER_MODIFIABLE
does not contain all user modifiable flags - at least EXT4_JOURNAL_FL and
EXT4_EXTENTS_FL have special handling and can be modified even if they are
not in EXT4_FL_USER_MODIFIABLE bitmask. So this patch needs more tweaking.
Honza
> ---
> fs/ext4/ext4.h | 1 +
> fs/ext4/ioctl.c | 28 +++++++++++++++++++++++-----
> 2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index ea31931386ec..a77a15df15b0 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -395,6 +395,7 @@ struct flex_groups {
> #define EXT4_FL_USER_VISIBLE 0x304BDFFF /* User visible flags */
> #define EXT4_FL_USER_MODIFIABLE 0x204380FF /* User modifiable flags */
>
> +/* Flags we can manipulate with through EXT4_IOC_FSSETXATTR */
> #define EXT4_FL_XFLAG_VISIBLE (EXT4_SYNC_FL | \
> EXT4_IMMUTABLE_FL | \
> EXT4_APPEND_FL | \
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 1bb7df5e4536..540bababfec1 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -412,6 +412,10 @@ static inline __u32 ext4_iflags_to_xflags(unsigned long iflags)
> return xflags;
> }
>
> +#define EXT4_SUPPORTED_FS_XFLAGS (FS_XFLAG_SYNC | FS_XFLAG_IMMUTABLE | \
> + FS_XFLAG_APPEND | FS_XFLAG_NODUMP | \
> + FS_XFLAG_NOATIME | FS_XFLAG_PROJINHERIT)
> +
> /* Transfer xflags flags to internal */
> static inline unsigned long ext4_xflags_to_iflags(__u32 xflags)
> {
> @@ -456,12 +460,22 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> if (get_user(flags, (int __user *) arg))
> return -EFAULT;
>
> + if (flags & ~EXT4_FL_USER_VISIBLE)
> + return -EOPNOTSUPP;
> + /*
> + * chattr(1) grabs flags via GETFLAGS, modifies the result and
> + * passes that to SETFLAGS. So we cannot easily make SETFLAGS
> + * more restrictive than just silently masking off visible but
> + * not settable flags as we always did.
> + */
> + flags &= EXT4_FL_USER_MODIFIABLE;
> + if (ext4_mask_flags(inode->i_mode, flags) != flags)
> + return -EOPNOTSUPP;
> +
> err = mnt_want_write_file(filp);
> if (err)
> return err;
>
> - flags = ext4_mask_flags(inode->i_mode, flags);
> -
> inode_lock(inode);
> err = ext4_ioctl_setflags(inode, flags);
> inode_unlock(inode);
> @@ -866,13 +880,17 @@ resizefs_out:
> if (!inode_owner_or_capable(inode))
> return -EACCES;
>
> + if (fa.fsx_xflags & ~EXT4_SUPPORTED_FS_XFLAGS)
> + return -EOPNOTSUPP;
> +
> + flags = ext4_xflags_to_iflags(fa.fsx_xflags);
> + if (ext4_mask_flags(inode->i_mode, flags) != flags)
> + return -EOPNOTSUPP;
> +
> err = mnt_want_write_file(filp);
> if (err)
> return err;
>
> - flags = ext4_xflags_to_iflags(fa.fsx_xflags);
> - flags = ext4_mask_flags(inode->i_mode, flags);
> -
> inode_lock(inode);
> flags = (ei->i_flags & ~EXT4_FL_XFLAG_VISIBLE) |
> (flags & EXT4_FL_XFLAG_VISIBLE);
> --
> 2.6.6
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2016-10-06 10:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-05 12:42 [PATCH 0/2] ext4: Inode flags handling Jan Kara
2016-10-05 12:42 ` [PATCH 1/2] ext4: Be more strict when verifying flags set via SETFLAGS ioctls Jan Kara
2016-10-06 10:35 ` Jan Kara [this message]
2016-10-05 12:42 ` [PATCH 2/2] ext4: Inode flags diet Jan Kara
2016-11-24 3:44 ` Andreas Dilger
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=20161006103548.GA31055@quack2.suse.cz \
--to=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).