From: edward_at_paradigm4.com.au
Date: Mon 21 Jan 2002 - 12:15:11 GMT
Just discovered something I didn't like.
It is possible to start a separate instance of klogd
inside non-zero context, which can "steal" some kernel
messages from the main klogd/syslogd
I'm not thrilled with the idea that they can view /proc/kmsg either.
Below is a simple "fix".
dmesg and klogd under vserver will fail.
--- linux-2.4.17/kernel/printk.c.orig Sat Dec 22 04:42:04 2001
+++ linux-2.4.17/kernel/printk.c Mon Jan 21 22:06:13 2002
@@ -168,6 +168,8 @@
char c;
int error = 0;
+ if(current->s_context!=0) return -EPERM;
+
switch (type) {
case 0: /* Close log */
break;
On more general note, it may be a good idea to go through the whole
/proc/ tree and decide what's to be banned from non-root contexts.
I discovered the /proc/kmsg issue because we wanted to log the
use/abuse of s_context call so I came up with a few patches.
While testing these I found out that the kernel log messages
can be accessed from any context by simply typing dmesg.
The urls of the "logging" patches are below if it's of any interest.
http://vserver.digitalangel.com.au/patch-2.4.17ctx-5-s_info
http://vserver.digitalangel.com.au/patch-2.4.17ctx-5-log
to be applied after
http://vserver.digitalangel.com.au/patch-2.4.17ctx-5-signal
which I sent earlier or here's the combined one:
http://vserver.digitalangel.com.au/patch-2.4.17ctx-5-log+signal
hth
Ed