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
next prev 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.