From: Dave Chinner <david@fromorbit.com>
To: Dwight Engen <dwight.engen@oracle.com>
Cc: Brian Foster <bfoster@redhat.com>, xfs@oss.sgi.com
Subject: Re: [PATCH v4 6/7] xfs: check that eofblocks ioctl caller can write matched inodes
Date: Wed, 24 Jul 2013 13:40:07 +1000 [thread overview]
Message-ID: <20130724034007.GN19986@dastard> (raw)
In-Reply-To: <20130719121321.5d78beeb@oracle.com>
On Fri, Jul 19, 2013 at 12:13:21PM -0400, Dwight Engen wrote:
> On Fri, 19 Jul 2013 16:02:21 +1000
> Dave Chinner <david@fromorbit.com> wrote:
>
> > On Wed, Jul 17, 2013 at 11:47:46AM -0400, Dwight Engen wrote:
> > > Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
> >
> > What's the reason for this patch?
>
> Its trying to ensure we only allow the XFS_IOC_FREE_EOFBLOCKS
> caller to affect the indoes they should be able to.
> http://oss.sgi.com/archives/xfs/2013-06/msg00955.html has a bit more
> background. This isn't really related to user namespaces per-se, so I
> guess it should be a separate patch, but since I modified the
> eofblocks structure I was trying to fix this as well.
background needs to be in the commit message.
>
> > > ---
> > > fs/xfs/xfs_fs.h | 1 +
> > > fs/xfs/xfs_icache.c | 4 ++++
> > > fs/xfs/xfs_ioctl.c | 2 ++
> > > 3 files changed, 7 insertions(+)
> > >
> > > diff --git a/fs/xfs/xfs_fs.h b/fs/xfs/xfs_fs.h
> > > index 7eb4a5e..aee4b12 100644
> > > --- a/fs/xfs/xfs_fs.h
> > > +++ b/fs/xfs/xfs_fs.h
> > > @@ -361,6 +361,7 @@ struct xfs_fs_eofblocks {
> > > #define XFS_EOF_FLAGS_GID (1 << 2) /* filter by gid
> > > */ #define XFS_EOF_FLAGS_PRID (1 << 3) /* filter by
> > > project id */ #define XFS_EOF_FLAGS_MINFILESIZE (1 << 4) /*
> > > filter by min file size */ +#define XFS_EOF_FLAGS_PERM_CHECK
> > > (1 << 5) /* check can write inode */ #define
> > > XFS_EOF_FLAGS_VALID \ (XFS_EOF_FLAGS_SYNC | \
> > > XFS_EOF_FLAGS_UID | \
> > > diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c
> > > index d873ab9e..728283a 100644
> > > --- a/fs/xfs/xfs_icache.c
> > > +++ b/fs/xfs/xfs_icache.c
> > > @@ -1247,6 +1247,10 @@ xfs_inode_free_eofblocks(
> > > if (!xfs_inode_match_id(ip, eofb))
> > > return 0;
> > >
> > > + if (eofb->eof_flags & XFS_EOF_FLAGS_PERM_CHECK &&
> > > + inode_permission(VFS_I(ip), MAY_WRITE))
> > > + return 0;
> >
> > This assumes we are walking fully instantiated VFS inodes. That's
> > not necessarily true - we may be walking inodes that have already
> > been dropped from the VFS and are waiting for background reclaim to
> > clean them up. I suspect that this doesn't need to be done - we
> > normally stop background modification processes like this when we
> > convert the filesystem to read-only. I suspect the eof-blocks scan
> > code is missing that, and so it can potentially run on a RO
> > filesystem. That needs fixing similar to the way we stop and start
> > the periodic log work...
>
> So if there isn't a good way to check per-inode, maybe for now we
> should just restrict the ioctl caller to be capable(CAP_SYS_ADMIN)?
What, exactly, are you trying to check here?
> > Also, gcc should throw warnings on that code (strange, it didn't
> > here on gcc-4.7) as it needs more parenthesis. i.e
>
> I don't think it needs them (& is higher precedence than &&), but I can
> add them for clarity if you like.
I know what the precedence is, but code that looks like:
(a & b && c & d && b & d && ..)
needs time to verify that it is correct. Indeed, when I see the
above, I think "was it supposed to be":
(a && b && c && d && b & d && ..)
Parenthesis remove any ambiguity in intention here - they clearly
separate intended logic from typos. Same goes for | vs ||....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-07-24 3:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-17 15:47 [PATCH v4 6/7] xfs: check that eofblocks ioctl caller can write matched inodes Dwight Engen
2013-07-19 6:02 ` Dave Chinner
2013-07-19 16:13 ` Dwight Engen
2013-07-24 3:40 ` Dave Chinner [this message]
2013-07-22 16:00 ` Dwight Engen
2013-07-24 3:46 ` Dave Chinner
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=20130724034007.GN19986@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=dwight.engen@oracle.com \
--cc=xfs@oss.sgi.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.