linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).