[Lxc-users] Kernel 2.6.33-rc6, 3 bugs container specific.

[Serge E. Hallyn]

Quoting Daniel Lezcano (daniel.lezcano at free.fr):
> Serge E. Hallyn wrote:
> >Quoting Daniel Lezcano (daniel.lezcano at free.fr):
> >>Serge E. Hallyn wrote:
> >>>Quoting Jean-Marc Pigeon (jmp at safe.ca):
> >>>>Hello,
> >>>>
> >>>>
> >>>>>I was wondering out loud about the best design to solve his problem.
> >>>>>
> >>>>>If we try to redirect kernel-generated messages to containers, we have
> >>>>>several problems, including whether we need to duplicate the messages
> >>>>>to the host container.  So in one sense it seems more flexible to
> >>>>>	1. send everything to host syslog
> >>>>		No, if we do that all CONTs message will reach
> >>>>		the same bucket and it will be difficult to sort
> >>>>		them out..
> >>>>		CONT sys_admin and HOST sys_admin could be different
> >>>>		"entity", so you debug CONT config and critical
> >>>>		needed information reach HOST (which you do not 		have access
> >>>>to).
> >>>Yes, so a privileged task on HOST must pass that information back to
> >>>you on CONT.  That is not a valid complaint imo.  But how to sort the
> >>>msgs out is a valid question.
> >>>
> >>>We need some sort of identifier, unique system-wide, attached to.. something.
> >>>Is ifindex unique system-wide right now?  Oh, IIRC it is, but we wnat it to
> >>>be containerized, so that would be a bad choice :)
> >>>
> >>>>>	2. clamp down on syslog use by processes not in the init_user_ns
> >>>>		Could give me more detail??...
> >>>Simplest choices would be to just refuse sys_syslog() and open(/proc/kmsg)
> >>>altogether from a container, or to only allow reading/writing messages
> >>>to own syslog.  (I had hoped to find time to try out the second option but
> >>>simply haven't had the time, and it doesn't look like I will very soon.
> >>>So if anyone else wants to, pls jump at it...)
> >>>
> >>>Then /proc/kmsg can provide what I described above through a FUSE file,
> >>>and if, as you mentioned, the container unmounts the FUSE fs and gets
> >>>to real procfs, they just get nothing.
> >>>
> >>>>>	3. let the userspace on the host copy messages into a socket or
> >>>>>	   file so child container can pretend it has real syslog.
> >>>>		So you trap printk message from CONT on the HOST and
> >>>>		redirect them on CONT but on a standard syslog channel.
> >>>>		Seem OK to me, as long /proc/kmsg is not existing
> >>>>		(/dev/null) in the CONT file tree.
> >>We have:
> >>       * Commands to sys_syslog:
> >>       *
> >>       *      0 -- Close the log.  Currently a NOP.
> >>       *      1 -- Open the log. Currently a NOP.
> >>       *      2 -- Read from the log.
> >>       *      3 -- Read all messages remaining in the ring buffer.
> >>       *      4 -- Read and clear all messages remaining in the ring buffer
> >>       *      5 -- Clear ring buffer.
> >>       *      6 -- Disable printk to console
> >>       *      7 -- Enable printk to console
> >>       *      8 -- Set level of messages printed to console
> >>       *      9 -- Return number of unread characters in the log buffer
> >>       *     10 -- Return size of the log buffer
> >>
> >>And add:
> >>      *     11 -- create a new ring buffer for the current process
> >>and its childs
> >>
> >>
> >>We have, let's say a global ring buffer keep untouched, used by
> >>syslog(2) and printk. When we create a new ring buffer, we allocate
> >>it and assign to the nsproxy (global ring buffer is the default in
> >>the nsproxy).
> >>
> >>The prink keeps writing in the global ring buffer and the syslog(2)
> >>writes to the "namespaced" ring buffer.
> >>
> >>Does it makes sense ?
> >
> >Yeah, it's a nice alternative.  Though (1) there is something to be said for
> >forcing a new ring buffer upon clone(CLONE_NEWUSER), and (2) assuming the
> >new ring buffer is pointed to from nsproxy, it might be frowned upon to do
> >an unshare/clone action in yet another way.

> Why do you want to tie clone(CLONE_NEWUSER) with a new ring buffer ?
> I mean one may want to use CLONE_NEWUSER but keep the ring buffer, no ?

Hmm, well yesterday I was thinking no, but I guess you're right.  I may
be wanting to remap userids and not contain root.

I still like your syslog command 11, but assuming we want to keep the
syslog_ns on nsproxy, I think we really need to stick to clone/unshare.
So if we want to add a CLONE_SYSLOG flag, we have to wait until eclone
gets us more clone flags :)  Or, pull out the eclone patchset from
linux-cr and make it prereq for this.

> >I still think our first concern should be safety, and that we should consider
> >just adding 'struct syslog_struct' to nsproxy, and making that NULL on a
> >clone(CLONE_NEWUSER).  any sys_syslog() or /proc/kmsg access returns -EINVAL
> >after that.  Then we can discuss whether and how to target printks to
> >namespaces, and whether duplicates should be sent to parent namespaces.
> That makes sense to do it step by step. Targeting the printk is the
> more difficult, no ? I mean you should have always the destination
> namespace available which is not obvious when the printk is called
> from an interrupt context.
> 
> >After we start getting flexible with syslog, the next request will be for
> >audit flexibility.  I don't even know how our netlink support suffices for
> >that right now.
> >
> >(So, this all does turn into a big deal...)
> Mmh ... right.