re: /proc/kmsg

About this list Date view Thread view Subject view Author view Attachment view

From: Jacques Gelinas (
Date: Mon Jan 21 2002 - 16:11:23 EST

On Mon, 21 Jan 2002 23:15:11 -0500, wrote
> 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.

I agree. I have modified the patch this way

        if (!capable(CAP_SYS_ADMIN)) return -EPERM;

vservers do not have this capability by default and some people may want
to do some special jobs in vservers. It sounds a little more general than
just relying on the security context.

> 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 think that /proc is far too complex and too open (any module may add its own trick
in it). We would have to review it on a regular basis :-(

I want to write a new proc fs called vproc. It would simply be a stripped down
proc containing the processes and few other entries in proc. This way, we will
have the stuff needed by vservers and this will be enough.

What do you think ?

> which I sent earlier or here's the combined one:

I had already applied this one. I will publish the ctx-6 patch later this week.

Jacques Gelinas <>
vserver: run general purpose virtual servers on one box, full speed!

About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT