Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > Serge Hallyn <serge.hallyn@xxxxxxxxxxxxx> writes: > > > Introduce a system log namespace. The syslog ns is tied to a user > > namespace. You must create a new user namespace before you can create a > > new sylog ns. The syslog ns is created through a new command (11) to > > the __NR_syslog system call. > > > > Once a task enters a new syslog ns, it's "dmesg", "dmesg -c" and > > /dev/kmsg actions affect only itself, so that user-created syslog > > messages no longer are confusingly combined in the host's syslog. > > "printk" itself always goes to the initial syslog_ns, and consoles > > belong only to the initial syslog_ns. However printks relating to a > > specific network namespace, for instance, can now be targeted to the > > syslog ns for the user ns which owns the network ns, aiding in debugging > > in a container. > > > > This patch is on top of the user namespace enhanced kernel at > > git://kernel.ubuntu.com/serge/quantal-userns. It is good enough to > > compile with stock ubuntu kernel options, boot, launch other syslog > > namespaces and exercise them. It will need help before it will compile > > with funky options like CONFIG_PRINTK=n. This is only being sent out to > > get feedback on the general idea. > > > > Comments greatly appreciated. > > > > (See https://wiki.ubuntu.com/LxcSyslogNs for background). > > Overall I would say the goal sounds well thought out. > > I am not a fan of how this ties into the user namespace. I would prefer > closer or looser ties. The recursive reference count loop where a > userns refers to a syslogns and that syslogns refers to the same userns > is unpleasant. We could make the nsproxy point to the syslog_ns, but this seemed simpler. Note that the syslog_ns does not need to pin the user_ns, since by design the user_ns owning a syslog_ns can't go away if the syslog_ns is still alive. But yes, the question of "what should point to the syslog_ns" is what has kept a syslog_ns from being seriously proposed since february 2010 :) Hm, wait. A nagging feeling made me look back, and I see that I do in fact pin the user_ns from the syslog_ns. I didn't mean to (and I don't release it :) and we don't need to. When a syslog_ns is created, it can only be inherited by child user_ns's, and its owner, the parent user_ns, can never go away until the child user_ns's go away. > The important case as I understand it is to handle injection of messages > into dmesg by userspace? 1. injection of messages into dmesg by userspace, 2. clearing of messages by userspace, but also 3. allowing appropriate kernel printks to be targeted to containers. > I would really like to see how messages from networking devices and > netfilter would be handled. Right now one of the ugliest bits of It would simply replace a printk(KERN_NOTICE "doing something\n"); with nsprintk(net->user_ns->syslog_ns, KERN_NOTICE "doing something\n"); I'm not yet clear on whether we'd want nsprintk to print to both the init_syslog_ns (with a ns prefix) and the child ns. > lowering the permissions in the network namespace is what do about the > commands that set the message loglevel. Here I'm not sure what you mean. > In general unless we can safely and sanely direct kernel messages into > this new dmesg I don't actually see the point of having another ring > buffer in the kernel. If the only success is userspace having the > syslog facility simply be unavailable seems more palatable. No I didn't do any in this patch, but directing kernel messages into the new dmesg was definately a goal and should be trivial now. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
