| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 9 Apr 2015 23:59:02 -0400
From: Jarod Wilson <jarod@...hat.com>
To: linux-kernel@...r.kernel.org
Cc: Jarod Wilson <jarod@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Alexey Dobriyan <adobriyan@...il.com>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Al Viro <viro@...iv.linux.org.uk>,
Miklos Szeredi <miklos@...redi.hu>,
Zefan Li <lizefan@...wei.com>, Oleg Nesterov <oleg@...hat.com>
Subject: [PATCH] fs/proc: allow larger /proc/<pid>/cmdline output
There are people who run java. Sometimes, when it misbehaves, they try to
figure out what's going on by dumping /proc/<pid>/cmdline, but the length
of that output is currently capped by PAGE_SIZE (so x86_64's 4k, in most
cases), and sometimes, java command lines are longer than 4k characters.
This change allows the user to request a larger max length, up to 4x
PAGE_SIZE, but the default out-of-the-box setting should keep things the
same as they ever were. The 4x maximum is somewhat arbitrary, but seemed
like it should be more than enough, because really, if you have more than
16k characters on your command line, you're probably doing it wrong...
I've tested this lightly with non-java shell commands with really long
parameters, and things are perfectly stable after several hundred
iterations of exercising things on a system booted with both
proc_pid_maxlen=8192 and 16384. I wouldn't call my testing exhaustive,
and I may not have considered something that will blow up horribly here,
so comments and clues welcomed.
Using single_open_size() looked less messy than giving proc_pid_cmdline()
its own .start op that would allow multiple buffers.
Note: I've only added this extended sizing for /proc/<pid>/cmdline output,
rather than for all /proc/<pid>/foo elements, thinking that nothing else
should ever really be that long, but anything that is can simply switch
from using the ONE() macro to the ONE_SIZE() macro.
CC: Andrew Morton <akpm@...ux-foundation.org>
CC: Alexey Dobriyan <adobriyan@...il.com>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Al Viro <viro@...iv.linux.org.uk>
CC: Miklos Szeredi <miklos@...redi.hu>
CC: Zefan Li <lizefan@...wei.com>
CC: Oleg Nesterov <oleg@...hat.com>
Signed-off-by: Jarod Wilson <jarod@...hat.com>
---
fs/proc/base.c | 42 +++++++++++++++++++++++++++++++++++++++---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 3f3d7ae..bb466c1 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -134,6 +134,30 @@ struct pid_entry {
NOD(NAME, (S_IFREG|(MODE)), \
NULL, &proc_single_file_operations, \
{ .proc_show = show } )
+#define ONE_SIZE(NAME, MODE, show) \
+ NOD(NAME, (S_IFREG|(MODE)), \
+ NULL, &proc_single_file_size_operations, \
+ { .proc_show = show } )
+
+/*
+ * Its hideous, but some java gunk winds up with a cmdline that is longer
+ * than PAGE_SIZE, and some people want to be able to see all of it for
+ * debugging purposes. Allocate at least PAGE_SIZE, and allow the user to
+ * ask for up to PAGE_SIZE << 2 (4x) to help with that situation.
+ */
+static unsigned long proc_pid_maxlen = PAGE_SIZE;
+static int set_proc_pid_maxlen(char *str)
+{
+ if (!str)
+ return 0;
+
+ proc_pid_maxlen = simple_strtoul(str, &str, 0);
+ proc_pid_maxlen = max(PAGE_SIZE, proc_pid_maxlen);
+ proc_pid_maxlen = min(PAGE_SIZE << 2, proc_pid_maxlen);
+
+ return 1;
+}
+__setup("proc_pid_maxlen=", set_proc_pid_maxlen);
/*
* Count the number of hardlinks for the pid_entry table, excluding the .
@@ -204,7 +228,7 @@ static int proc_pid_cmdline(struct seq_file *m, struct pid_namespace *ns,
* per internal buffer allocation. See single_open(), traverse().
*/
BUG_ON(m->size < PAGE_SIZE);
- m->count += get_cmdline(task, m->buf, PAGE_SIZE);
+ m->count += get_cmdline(task, m->buf, proc_pid_maxlen);
return 0;
}
@@ -601,6 +625,18 @@ static const struct file_operations proc_single_file_operations = {
.release = single_release,
};
+static int proc_single_open_size(struct inode *inode, struct file *filp)
+{
+ return single_open_size(filp, proc_single_show, inode, proc_pid_maxlen);
+}
+
+static const struct file_operations proc_single_file_size_operations = {
+ .open = proc_single_open_size,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode)
{
@@ -2560,7 +2596,7 @@ static const struct pid_entry tgid_base_stuff[] = {
#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
ONE("syscall", S_IRUSR, proc_pid_syscall),
#endif
- ONE("cmdline", S_IRUGO, proc_pid_cmdline),
+ ONE_SIZE("cmdline", S_IRUGO, proc_pid_cmdline),
ONE("stat", S_IRUGO, proc_tgid_stat),
ONE("statm", S_IRUGO, proc_pid_statm),
REG("maps", S_IRUGO, proc_pid_maps_operations),
@@ -2906,7 +2942,7 @@ static const struct pid_entry tid_base_stuff[] = {
#ifdef CONFIG_HAVE_ARCH_TRACEHOOK
ONE("syscall", S_IRUSR, proc_pid_syscall),
#endif
- ONE("cmdline", S_IRUGO, proc_pid_cmdline),
+ ONE_SIZE("cmdline", S_IRUGO, proc_pid_cmdline),
ONE("stat", S_IRUGO, proc_tid_stat),
ONE("statm", S_IRUGO, proc_pid_statm),
REG("maps", S_IRUGO, proc_tid_maps_operations),
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists