From: Brian Foster <bfoster@redhat.com>
To: Dwight Engen <dwight.engen@oracle.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v7 6/7] xfs: add capable check to free eofblocks ioctl
Date: Tue, 30 Jul 2013 08:33:39 -0400 [thread overview]
Message-ID: <51F7B2A3.7030007@redhat.com> (raw)
In-Reply-To: <20130729230705.128e4509@oracle.com>
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).
> + 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);
Brian
> if (copy_from_user(&eofb, arg, sizeof(eofb)))
> return -XFS_ERROR(EFAULT);
>
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-07-30 12:37 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 [this message]
2013-07-30 23:27 ` Dave Chinner
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=51F7B2A3.7030007@redhat.com \
--to=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.