All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Eric Sandeen <sandeen@redhat.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: [PATCH 2/4] xfs: reject completely bogus remount options
Date: Fri, 11 Oct 2013 14:11:18 -0500	[thread overview]
Message-ID: <52584D56.7090902@sandeen.net> (raw)
In-Reply-To: <52584C8A.1060808@redhat.com>

There's a long comment about handling non-remountable
options in xfs_fs_remount, but nothing addresses the case
of completely bogus mount options at remount time, which
can lead to some severe strangeness:

# for I in `seq 1 10`; do mount -o remount,noacl /mnt/test2; done
# for I in `seq 1 10`; do mount -o remount,badoption /mnt/test2; done
# grep sdb4 /etc/mtab
/dev/sdb4 /mnt/test2 xfs rw,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption 0 0

This is a bit of a hack, but we can re-use xfs_parseargs()
with a dummy mount struct to just vet all of the remount
options which were passed in.  With this, we get a saner
result:

[44898.102990] EXT4-fs (sdb4): Unrecognized mount option "badoption" or missing value

if we try to remount with something ridiculous.

In the long run we should probably revamp a lot of the mount option
handling...

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---

Note, not really sure what KM_* flag would be appropriate here,
if it fails, it really is ok, other than missing the verification.
But maybe that's too "nice?"

commit 72e6ddd901dc8a8ecb835324eb4e11b0d7ad8cf8
Author: Eric Sandeen <sandeen@redhat.com>
Date:   Fri Oct 11 14:03:59 2013 -0500

    xfs: reject completely bogus remount options
    
    There's a long comment about handling non-remountable
    options in xfs_fs_remount, but nothing addresses the case
    of completely bogus mount options at remount time, which
    can lead to some severe strangeness:
    
    # for I in `seq 1 10`; do mount -o remount,noacl /mnt/test2; done
    # for I in `seq 1 10`; do mount -o remount,badoption /mnt/test2; done
    # grep sdb4 /etc/mtab
    /dev/sdb4 /mnt/test2 xfs rw,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,noacl,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption,badoption 0 0
    
    This is a bit of a hack, but we can re-use xfs_parseargs()
    with a dummy mount struct to just vet all of the remount
    options which were passed in.  With this, we get a saner
    result:
    
    [44898.102990] EXT4-fs (sdb4): Unrecognized mount option "badoption" or missing value
    
    if we try to remount with something ridiculous.
    
    In the long run we should probably revamp a lot of the mount option
    handling...
    
    Signed-off-by: Eric Sandeen <sandeen@redhat.com>

diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c
index 15188cc..00a06d6 100644
--- a/fs/xfs/xfs_super.c
+++ b/fs/xfs/xfs_super.c
@@ -1202,11 +1202,25 @@ xfs_fs_remount(
 	int			*flags,
 	char			*options)
 {
-	struct xfs_mount	*mp = XFS_M(sb);
+	struct xfs_mount	*mp = XFS_M(sb), *dummy_mp;
 	substring_t		args[MAX_OPT_ARGS];
 	char			*p;
 	int			error;
 
+	/*
+	 * Check all the mount options presented to be sure
+	 * there's nothing too crazy in there.  Non-remountable
+	 * but valid options are a different issue.
+	 */
+	dummy_mp = kmem_zalloc(sizeof(*dummy_mp), KM_MAYFAIL);
+	if (dummy_mp) {
+		dummy_mp->m_super = sb;
+		error = xfs_parseargs(dummy_mp, options);
+		kfree(dummy_mp);
+		if (error)
+			return -error;
+	}
+
 	while ((p = strsep(&options, ",")) != NULL) {
 		int token;
 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2013-10-11 19:11 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-11 19:07 [PATCH 0/4] xfs: old lost patches Eric Sandeen
2013-10-11 19:09 ` [PATCH 1/4] xfs: remove newlines from 3 xfs_alert_tag error strings Eric Sandeen
2013-10-11 21:59   ` Mark Tinguely
2013-10-12  1:45     ` Eric Sandeen
2013-10-12  1:59   ` [PATCH 1/4 V2] xfs: remove newlines from strings passed to __xfs_printk Eric Sandeen
2013-10-12 21:07     ` Mark Tinguely
2013-10-11 19:11 ` Eric Sandeen [this message]
2013-10-11 21:34   ` [PATCH 2/4] xfs: reject completely bogus remount options Mark Tinguely
2013-10-12  1:40     ` Eric Sandeen
2013-10-12 21:11       ` Mark Tinguely
2013-10-13 21:52   ` Dave Chinner
2013-10-14  2:42     ` Eric Sandeen
2013-10-14  4:45       ` Dave Chinner
2013-10-15 18:13         ` Eric Sandeen
2013-10-11 19:12 ` [PATCH 3/4] xfs: don't emit corruption noise on fs probes Eric Sandeen
2013-10-11 21:21   ` Mark Tinguely
2013-10-15 19:42   ` Christoph Hellwig
2013-10-11 19:14 ` [PATCH 4/4] xfs: don't break from growfs ag update loop on error Eric Sandeen
2013-10-17 18:51 ` [PATCH 0/4] xfs: old lost patches Ben Myers

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=52584D56.7090902@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=sandeen@redhat.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.