From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
siddhesh@gotplt.org, Florian Weimer <fweimer@redhat.com>
Subject: [RESEND][PATCH v3] proc: Escape more characters in /proc/mounts output
Date: Thu, 7 Jan 2021 15:41:13 +0530 [thread overview]
Message-ID: <20210107101113.368139-1-siddhesh@gotplt.org> (raw)
When a filesystem is mounted with a blank name like so:
# mount '' bad -t tmpfs
its name entry in /proc/mounts is blank causing the line to start
with a space.
/mnt/bad tmpfs rw,seclabel,relatime,inode64 0 0
Further, the name could start with a hash, causing the entry to look
like this (leading space added so that git does not strip it out):
# /mnt/bad tmpfs rw,seclabel,relatime,inode64 0 0
This breaks getmntent and any code that aims to parse fstab as well as
/proc/mounts with the same logic since they need to strip leading
spaces or skip over comments, due to which they report incorrect
output or skip over the line respectively.
This fix resolves both issues by (1) treating blank names the same way
as not having a name and (2) by escaping the hash character into its
octal encoding, which getmntent can then decode and print correctly.
As far as file parsing is concerned, these are the only additional
cases to cater for since they cover all characters that have a special
meaning in that context.
Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
Cc: Florian Weimer <fweimer@redhat.com>
---
fs/namespace.c | 5 +++++
fs/proc_namespace.c | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index d2db7dfe232b..2f81f1c7f20a 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -3421,6 +3421,11 @@ SYSCALL_DEFINE5(mount, char __user *, dev_name, char __user *, dir_name,
if (IS_ERR(kernel_dev))
goto out_dev;
+ if (kernel_dev && !kernel_dev[0]) {
+ kfree(kernel_dev);
+ kernel_dev = NULL;
+ }
+
options = copy_mount_options(data);
ret = PTR_ERR(options);
if (IS_ERR(options))
diff --git a/fs/proc_namespace.c b/fs/proc_namespace.c
index eafb75755fa3..6d7e47750781 100644
--- a/fs/proc_namespace.c
+++ b/fs/proc_namespace.c
@@ -83,7 +83,7 @@ static void show_mnt_opts(struct seq_file *m, struct vfsmount *mnt)
static inline void mangle(struct seq_file *m, const char *s)
{
- seq_escape(m, s, " \t\n\\");
+ seq_escape(m, s, " \t\n\\#");
}
static void show_type(struct seq_file *m, struct super_block *sb)
--
2.29.2
reply other threads:[~2021-01-07 10:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20210107101113.368139-1-siddhesh@gotplt.org \
--to=siddhesh@gotplt.org \
--cc=fweimer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).