All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <npiggin@suse.de>
To: Christoph Hellwig <hch@lst.de>
Cc: viro@zeniv.linux.org.uk, jack@suse.cz, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] check ATTR_SIZE contraints in inode_change_ok
Date: Wed, 9 Jun 2010 17:33:36 +1000	[thread overview]
Message-ID: <20100609073336.GV26335@laptop> (raw)
In-Reply-To: <20100601113937.GB4929@lst.de>

On Tue, Jun 01, 2010 at 01:39:37PM +0200, Christoph Hellwig wrote:
> Make sure we check the truncate constraints early on in ->setattr by adding
> those checks to inode_change_ok.  Also clean up and document inode_change_ok
> to make this obvious.
> 
> As a fallout we don't have to call inode_newsize_ok from simple_setsize and
> simplify it down to a truncate_setsize which doesn't return an error.  This
> simplifies a lot of setattr implementations and means we use truncate_setsize
> almost everywhere.  Get rid of fat_setsize now that it's trivial and mark
> ext2_setsize static to make the calling convention obvious.
> 
> Keep the inode_newsize_ok in vmtruncate for now as all callers need an
> audit for it's removal anyway.
> 
> Note: setattr code in ecryptfs doesn't call inode_change_ok at all and
> needs a deeper audit, but that is left for later.
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Index: linux-2.6/fs/attr.c
> ===================================================================
> --- linux-2.6.orig/fs/attr.c	2010-06-01 12:19:47.987277079 +0200
> +++ linux-2.6/fs/attr.c	2010-06-01 12:48:26.063005672 +0200
> @@ -14,35 +14,53 @@
>  #include <linux/fcntl.h>
>  #include <linux/security.h>
>  
> -/* Taken over from the old code... */
> -
> -/* POSIX UID/GID verification for setting inode attributes. */
> +/**
> + * inode_change_ok - check if attribute changes to an inode are allowed
> + * @inode:	inode to check
> + * @attr:	attributes to change
> + *
> + * Check if we are allowed to change the attributes contained in @attr
> + * in the given inode.  This includes the normal unix access permission
> + * checks, as well as checks for rlimits and others.
> + *
> + * Should be called as the first thing in ->setattr implementations,
> + * possibly after taking additional locks.
> + */
>  int inode_change_ok(const struct inode *inode, struct iattr *attr)
>  {
> -	int retval = -EPERM;
>  	unsigned int ia_valid = attr->ia_valid;
>  
> +	/*
> +	 * First check size constraints.  These can't be overriden using
> +	 * ATTR_FORCE.
> +	 */
> +	if (attr->ia_mode & ATTR_SIZE) {
> +		int error = inode_newsize_ok(inode, attr->ia_size);
> +		if (error)
> +			return error;
> +	}

Hmm, I don't know if we can do this unless you have audited the
filesystems (in which case they should be on the cc list of this
pach).

The problem is whether the i_size is valid and stable at this
point. And it doesn't help even if you do leave the inode_newsize_ok
check inside the vmtruncate part of the fs if the check incorrectly
fails here.

ocfs2 performs inode_change_ok outside ocfs2_rw_lock and
ocfs2_inode_lock, and inode_newsize_ok inside; cifs holds i_lock
while checking inode_newsize_ok and updating size; gfs2 inside
gfs2_trans_begin.

Haven't looked closely at all fses or the consequences of the above.

Thoughts?

  parent reply	other threads:[~2010-06-09  7:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-01 11:39 [PATCH 0/2] new truncate sequence, part3 Christoph Hellwig
2010-06-01 11:39 ` [PATCH 1/2] always call inode_change_ok early in ->setattr Christoph Hellwig
2010-06-01 11:39 ` [PATCH 2/2] check ATTR_SIZE contraints in inode_change_ok Christoph Hellwig
2010-06-01 11:49   ` Steven Whitehouse
2010-06-01 11:47     ` Christoph Hellwig
2010-06-09  7:33   ` Nick Piggin [this message]
2010-06-09  9:41     ` Jan Kara
2010-06-09 10:06       ` Nick Piggin
2010-06-09 10:07       ` Christoph Hellwig
2010-06-09 10:26         ` Nick Piggin
2010-06-10  8:21           ` Christoph Hellwig
2010-06-09 10:59         ` Steven Whitehouse

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=20100609073336.GV26335@laptop \
    --to=npiggin@suse.de \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --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.