Syslog are now containerized

Added syslog.c such container /proc/kmsg and host /proc/kmsg do not leak in each other.
Running rsyslog daemon within a container won't destroy host kernel messages.

! I think my patch is fundamentally wrong anyway: we should not ! use current's context at vprintk like i did. We should use an ! optional passed-in context from those callsites where we want to, ! and default to init otherwise. That means
!
! 1. put the core of vprintk() into vnsprintk() which takes a syslog ! namespace as argument
!
! 2. make vprintk() a wrapper around vnsprintk() which passes in ! init_syslog_ns to vnsprintk(). printk can remain unchanged. !
! 4. make nsprintk() a wrapper around vnsprintk() which takes a syslog ! ns argument and pass it to vnsprintk()
!

! 3. do_syslog() can obviously be containerized the same way it ! is now.
!
! 4. take a printk call like the iptables ones you want and turn ! int into nsprintk syscall.
!
! The very comment above printk explains why I was an idiot to write ! let alone send that patch.

Quoted 4 lines · Jean-Marc Pigeon

Added syslog.c such container /proc/kmsg and host /proc/kmsg do not leak in each other.
Running rsyslog daemon within a container won't destroy host kernel messages.

Thanks Jean-Marc. But this really isn't doing most of what I'd recommended in my last emails (both public and private. In particular:

include/linux/user_namespace.h struct user_namespace { · line 17

Quoted 8 lines

index cc4f453..3d0c73e 100644

include/linux/user_namespace.h +1 -0

@@ -14,6 +14,7 @@ struct user_namespace {
 	struct hlist_head	uidhash_table[UIDHASH_SZ];
 	struct user_struct	*creator;
 	struct work_struct	destroyer;
+	struct syslog_ns        *syslog;

syslog_ns should be moved into nsproxy and unshared with a separate clone(CLONE_SYSLOG);

include/linux/user_namespace.h struct user_namespace {

Quoted 13 lines

include/linux/user_namespace.h +2 -9

-static void emit_log_char(char c)
+static void emit_log_char(struct syslog_ns *syslog_ns, char c)
 {
-	LOG_BUF(log_end) = c;
-	log_end++;
-	if (log_end - log_start > log_buf_len)
-		log_start = log_end - log_buf_len;
-	if (log_end - con_start > log_buf_len)
-		con_start = log_end - log_buf_len;
-	if (logged_chars < log_buf_len)
-		logged_chars++;
+	LOG_BUF(syslog_ns, sys_log_end) = c;

Taking syslog_ns from current in emit_log_char is not right. Emit_log_char() is called from printk which (the comment above printk warns us) can be called from any context.

That was why I suggested:

Quoted 19 lines

! I think my patch is fundamentally wrong anyway: we should not ! use current's context at vprintk like i did. We should use an ! optional passed-in context from those callsites where we want to, ! and default to init otherwise. That means
!
! 1. put the core of vprintk() into vnsprintk() which takes a syslog ! namespace as argument
!
! 2. make vprintk() a wrapper around vnsprintk() which passes in ! init_syslog_ns to vnsprintk(). printk can remain unchanged. !
! 4. make nsprintk() a wrapper around vnsprintk() which takes a syslog ! ns argument and pass it to vnsprintk()
!
! 3. do_syslog() can obviously be containerized the same way it ! is now.
!
! 4. take a printk call like the iptables ones you want and turn ! int into nsprintk syscall.

Quoted 10 lines · Serge E. Hallyn

Quoted 4 lines · Jean-Marc Pigeon

Added syslog.c such container /proc/kmsg and host /proc/kmsg do not leak in each other.
Running rsyslog daemon within a container won't destroy host kernel messages.

Thanks Jean-Marc. But this really isn't doing most of what I'd recommended in my last emails (both public and private. In particular:

Quoted 11 lines

include/linux/user_namespace.h struct user_namespace { · line 17

Quoted 8 lines

index cc4f453..3d0c73e 100644

include/linux/user_namespace.h +1 -0

@@ -14,6 +14,7 @@ struct user_namespace {
 	struct hlist_head	uidhash_table[UIDHASH_SZ];
 	struct user_struct	*creator;
 	struct work_struct	destroyer;
+	struct syslog_ns        *syslog;

syslog_ns should be moved into nsproxy and unshared with a separate clone(CLONE_SYSLOG);

I agree. Keeping it in the user_namespace is strange. It should be in the nsproxy along with all of the other namespace pointers.

Quoted 18 lines

include/linux/user_namespace.h struct user_namespace {

Quoted 13 lines

include/linux/user_namespace.h +2 -9

-static void emit_log_char(char c)
+static void emit_log_char(struct syslog_ns *syslog_ns, char c)
 {
-	LOG_BUF(log_end) = c;
-	log_end++;
-	if (log_end - log_start > log_buf_len)
-		log_start = log_end - log_buf_len;
-	if (log_end - con_start > log_buf_len)
-		con_start = log_end - log_buf_len;
-	if (logged_chars < log_buf_len)
-		logged_chars++;
+	LOG_BUF(syslog_ns, sys_log_end) = c;

Taking syslog_ns from current in emit_log_char is not right. Emit_log_char() is called from printk which (the comment above printk warns us) can be called from any context.

Quoted 21 lines

That was why I suggested:

Quoted 19 lines

! I think my patch is fundamentally wrong anyway: we should not ! use current's context at vprintk like i did. We should use an ! optional passed-in context from those callsites where we want to, ! and default to init otherwise. That means
!
! 1. put the core of vprintk() into vnsprintk() which takes a syslog ! namespace as argument
!
! 2. make vprintk() a wrapper around vnsprintk() which passes in ! init_syslog_ns to vnsprintk(). printk can remain unchanged. !
! 4. make nsprintk() a wrapper around vnsprintk() which takes a syslog ! ns argument and pass it to vnsprintk()
!
! 3. do_syslog() can obviously be containerized the same way it ! is now.
!
! 4. take a printk call like the iptables ones you want and turn ! int into nsprintk syscall.

Definitely. Actually, I think we can go one step further and say that passing syslog_ns directly to nsprintk() is wrong too. It's wrong because we only know the namespace that's relevant to the printk contents -- and that won't usually be a syslog_ns.

Better to have the "find corresponding syslog_ns" logic inside nsprintk(). The great thing about doing it this way is if we ever decide to duplicate printk output to multiple containers it can be done inside nsprintk rather than doing a flag-day patch.

Quoted 10 lines · Serge E. Hallyn

Quoted 4 lines · Jean-Marc Pigeon

Added syslog.c such container /proc/kmsg and host /proc/kmsg do not leak in each other.
Running rsyslog daemon within a container won't destroy host kernel messages.

Thanks Jean-Marc. But this really isn't doing most of what I'd recommended in my last emails (both public and private. In particular:

Quoted 11 lines

include/linux/user_namespace.h struct user_namespace { · line 17

Quoted 8 lines

index cc4f453..3d0c73e 100644

include/linux/user_namespace.h +1 -0

@@ -14,6 +14,7 @@ struct user_namespace {
 	struct hlist_head	uidhash_table[UIDHASH_SZ];
 	struct user_struct	*creator;
 	struct work_struct	destroyer;
+	struct syslog_ns        *syslog;

syslog_ns should be moved into nsproxy and unshared with a separate clone(CLONE_SYSLOG);

I agree. Keeping it in the user_namespace is strange. It should be in the nsproxy along with all of the other namespace pointers.

Definitely. Actually, I think we can go one step further and say that passing syslog_ns directly to nsprintk() is wrong too. It's wrong because we only know the namespace that's relevant to the printk contents -- and that won't usually be a syslog_ns.

Better to have the "find corresponding syslog_ns" logic inside nsprintk(). The great thing about doing it this way is if we ever decide to duplicate printk output to multiple containers it can be done inside nsprintk rather than doing a flag-day patch.

Hello,

Quoted 23 lines · Matt Helsley

Quoted 21 lines · Serge E. Hallyn

Quoted 4 lines · Jean-Marc Pigeon

Added syslog.c such container /proc/kmsg and host /proc/kmsg do not leak in each other.
Running rsyslog daemon within a container won't destroy host kernel messages.

Thanks Jean-Marc. But this really isn't doing most of what I'd recommended in my last emails (both public and private. In particular:

include/linux/user_namespace.h struct user_namespace { · line 17

Quoted 8 lines

index cc4f453..3d0c73e 100644

include/linux/user_namespace.h +1 -0

@@ -14,6 +14,7 @@ struct user_namespace {
 	struct hlist_head	uidhash_table[UIDHASH_SZ];
 	struct user_struct	*creator;
 	struct work_struct	destroyer;
+	struct syslog_ns        *syslog;

syslog_ns should be moved into nsproxy and unshared with a separate clone(CLONE_SYSLOG);

Quoted 2 lines

I agree. Keeping it in the user_namespace is strange. It should be in the nsproxy along with all of the other namespace pointers.

I won't argue on this, I put it in user_namespace as serge proposed it at first and code implementation was a test/trial to me.
Setting syslog in nsproxy is fine to me (seems every body agree.. right?)

[...]

Quoted 10 lines

Definitely. Actually, I think we can go one step further and say that passing syslog_ns directly to nsprintk() is wrong too. It's wrong because we only know the namespace that's relevant to the printk contents -- and that won't usually be a syslog_ns.

Better to have the "find corresponding syslog_ns" logic inside nsprintk(). The great thing about doing it this way is if we ever decide to duplicate printk output to multiple containers it can be done inside nsprintk rather than doing a flag-day patch.

I tend to agree with you Matt.

I strongly disagree about what I understand about Serge proposal to add a "new printk".

What is the purpose of printk?
- Report a system data to the acting authority.

Syslog cant be sent to:
HOST: syslog
CONT: syslog
CONT: + HOST: syslog (duplication) Decision to duplicate syslog can be a printk privilege, lets says "according message level".

Decision to send to HOST: or CONT: syslog is depending execution context, which can be found back within the printk function itself (so no need to have ns_printk).

What is proposing Serge is to HARD CODE WITHIN kernel if we call the genuine printk or ns_printk, which is now a door wide open to coder interpretation ("is printk message containerised or not", my coding decision is as good as yours, and nobody will be satisfied).

My proposal is to say, if a ressource is containerized it must be used in containerized context, this means all printk are called within the context anyway.

What does that mean in real life?. lets call again the iptable example.

We already have a HOST: iptables set AND a CONT: iptables set. I have for my say, to keep consistency we MUST execute CONT: iptables rules checking within the CONT: context (which is not the case now... IMHO).

This approach is coherent, if a ressource (iptable, network device, file system,...) is defined AND managed within

CONT: report must be done TO CONT: (period). Means coding level need to take care ONLY about 'ressource' ownership, if it is "own" by CONT: then access it in its
CONT: context.

Keep in mind, A fully containerized system can be managed by someone with full privilege BUT NOT in charge of the host itself (IE: without host access).

My proposal is a clear cut, if a ressource is containerized report to CONT: (containerized) syslog... no question ask.

(sure enough printk could duplicate message to HOST:
my guess it won't be really needed in practical life, but I could be wrong....)

Tracking all of these accesses down and ensuring they are only done from "its container context" is difficult or impossible. It's not as easy as you seem to think. In some cases the same resource could be shared between containers. Which should we access it from then?

Quoted 4 lines

Keep in mind, A fully containerized system can be managed by someone with full privilege BUT NOT in charge of the host itself (IE: without host access).

Sure. (We're not there yet but I think we'd like to get there eventually.)

Quoted 2 lines

My proposal is a clear cut, if a ressource is containerized report to CONT: (containerized) syslog... no question ask.

That part of the proposal is simple and makes alot of sense. The ramifcations of it on kernel code are not simple and often there's no clean way to do it.

Hello,

[...]

Quoted 4 lines

Tracking all of these accesses down and ensuring they are only done from "its container context" is difficult or impossible. It's not as easy as you seem to think. In some cases the same resource could be shared between containers. Which should we access it from then?

How come?! ressources (a device, Iptable rules,...)

containerized within one container could be shared by another unrelated container?.

Does this means (simple example) someone change iptable rules for one container that could change another unrelated container behavior ?!...no way...

Quoted 6 lines

Quoted 2 lines

My proposal is a clear cut, if a ressource is containerized report to CONT: (containerized) syslog... no question ask.

That part of the proposal is simple and makes alot of sense. The ramifcations of it on kernel code are not simple and often there's no clean way to do it.

	Well, this trouble me somewhat....
	2.6.18-128.2.1.el5.028stab064.7 (just an example, I am using
	day to day), is containerising iptables an other syslogs 
	nice way....,

We are now 2.6.33 you are telling me what was experimented, learned, monthssss ago can't still be implemented in current kernel main stream?....

Quoted 3 lines · Jean-Marc Pigeon

Hello,

[...]

Yes. namespace boundaries only coincide if userspace chooses to make them coincide. For example, the tasks in a network namespace do not necessarily all share the same mount namespace.

Quoted 3 lines

Does this means (simple example) someone change iptable rules for one container that could change another unrelated container behavior ?!...no way...

Two "unrelated containers" would share the same iptables rules so long as they share a network namespace.

Quoted 7 lines

Quoted 3 lines

That part of the proposal is simple and makes alot of sense. The ramifcations of it on kernel code are not simple and often there's no clean way to do it.

	Well, this trouble me somewhat....
	2.6.18-128.2.1.el5.028stab064.7 (just an example, I am using
	day to day), is containerising iptables an other syslogs 
	nice way....,

Er.. you have a 2.6.18 kernel "containerising iptables an other syslogs"? I didn't think iptables supported network namespaces until somewhat recently. Is this an openvz-patched kernel you're talking about?

Careful. "no clean way to do it" does not mean "can't be done".

Added syslog.c such container /proc/kmsg and host /proc/kmsg do not leak in each other.
Running rsyslog daemon within a container won't destroy host kernel messages.
---

kernel/syslog.c new file +0 -0

new file mode 100644
index 0000000..69d30a9
@@ -0,0 +1,157 @@

Added syslog.c such container /proc/kmsg and host /proc/kmsg do not leak in each other.
Running rsyslog daemon within a container won't destroy host kernel messages.

Quoted 4 lines · Jean-Marc Pigeon

Added syslog.c such container /proc/kmsg and host /proc/kmsg do not leak in each other.
Running rsyslog daemon within a container won't destroy host kernel messages.

If the goal is to not destroy the host kernel messages the much simpler solution would be to simply disable /proc/kmsg in the container. I expect we can get that for free with a some bug fixes to the user namespace (aka if you are not in the global namespace you can't touch /proc/kmsg).

Additionally except for the possible exception of logging firewall rules I can't think of a case where I would want kernel printk's in anything other than the global kernel ring buffer.