From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: Dwight Engen <dwight.engen@oracle.com>, xfs@oss.sgi.com
Subject: Re: [PATCH v7 6/7] xfs: add capable check to free eofblocks ioctl
Date: Wed, 31 Jul 2013 09:27:46 +1000 [thread overview]
Message-ID: <20130730232746.GP13468@dastard> (raw)
In-Reply-To: <51F7B2A3.7030007@redhat.com>
On Tue, Jul 30, 2013 at 08:33:39AM -0400, Brian Foster wrote:
> On 07/29/2013 11:07 PM, Dwight Engen wrote:
> > Check for CAP_SYS_ADMIN since the caller can truncate preallocated
> > blocks from files they do not own nor have write access to. A more
> > fine grained access check was considered: require the caller to
> > specify their own uid/gid and to use inode_permission to check for
> > write, but this would not catch the case of an inode not reachable
> > via path traversal from the callers mount namespace.
> >
> > Add check for read-only filesystem to free eofblocks ioctl.
> >
> > Signed-off-by: Dwight Engen <dwight.engen@oracle.com>
> > ---
> > fs/xfs/xfs_ioctl.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> > index 6e72eff..b1990ac 100644
> > --- a/fs/xfs/xfs_ioctl.c
> > +++ b/fs/xfs/xfs_ioctl.c
> > @@ -1613,6 +1613,12 @@ xfs_file_ioctl(
> > struct xfs_fs_eofblocks eofb;
> > struct xfs_eofblocks keofb;
> >
> > + if (!capable(CAP_SYS_ADMIN))
> > + return -EPERM;
> > +
>
> I see that we aren't using XFS_ERROR() on the EPERM returns in
> xfs_file_ioctl(), but I see it used for other capability checks
> elsewhere (i.e., down in xfs_growfs_data()). Perhaps somebody can chime
> in as to the reasoning for that..? I guess it could be that we wouldn't
> want to fire a BUG() at the interface point (ioctl()) on debug kernels
> for every time a user attempts an operation they don't have the ability
> to perform (e.g., we should notice on internal failures, not when
> userspace sends us something wrong).
Essentially.
The error trapping is used to pinpoint where an error first occurs.
e.g. where a ENOMEM error is first detected. There might be tens of
memory allocations inside a transaction that is failing with ENOMEM
and shutting down, so tracking down where it came from is quite
hard. Hence trapping the first ENOMEM occurrence with a BUG() via
XFS_ERROR() will tell you exactly where it came from. Similarly,
some ioctls can return EINVAL for 20 different reasons (e.g.
xfs_swapext() path) and so trapping them can be useful if it's a
random failure that can't be captured otherwise.
Because all the EPERM checks are in the outer layers and generally
easy to spot, they are easy to test for and easy to track down when
they occur. Hence, in general, we don't need to trap them.
>
> > + if (IS_RDONLY(inode))
> > + return -XFS_ERROR(EROFS);
> > +
>
> This should probably be consistent with the other read-only checks in
> the ioctl code and check the xfs_mount structure:
>
> if (mp->m_flags & XFS_MOUNT_RDONLY)
> return -XFS_ERROR(EROFS);
Oh, I didn't even think about that - IS_RDONLY() actually checks the
superblock flag, so it's no different to checking the xfs_mount
flags. ;)
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-30 23:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-30 3:07 [PATCH v7 6/7] xfs: add capable check to free eofblocks ioctl Dwight Engen
2013-07-30 12:33 ` Brian Foster
2013-07-30 23:27 ` Dave Chinner [this message]
2013-07-30 23:16 ` Dave Chinner
2013-07-31 7:14 ` Gao feng
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=20130730232746.GP13468@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox