Quoting Matt Helsley ([email protected]): > On Thu, Feb 11, 2010 at 01:29:52PM -0600, Serge E. Hallyn wrote: > > Quoting Jean-Marc Pigeon ([email protected]): > > > Hello, > > > > > > > > > > > > > > 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: > > > [....] > > > > > > > > syslog_ns should be moved into nsproxy and unshared with a > > > > separate clone(CLONE_SYSLOG); > > > This this not a problem. > > > My understanding a new clone flag was not an option > > > as we are short in CLONE flag. > > > No design nor arch problem if we set CLONE_SYSLOG > > > to be 0x100000000 ????? > > > > > > If moved in nsproxy what is the hook to > > > get the "current context". (used current_user_ns() > > > as it was in user_namespace). > > > > > > > > > [...] > > > > > > > That was why I suggested: > > > [...] > > > > >! 4. take a printk call like the iptables ones you want and turn > > > > >! int into nsprintk syscall. > > > > >! > > > > > > If my understanding is right you propose to use a > > > special nsprintk to be used by iptable such > > > we can send "packet log" in "container context" > > > Right? > > > > > > Logic is weak. > > > > No logic is irrefutable :) Because: > > > > > 1) > > > The way I changed printk, so far, make of it a "de facto" > > > nsprintk. So when called from netfilter, nsprintk > > > is still stay in HOST: context. My understanding, > > > > No, it could be called from the context of a task in any > > random container. > > Your comments seem good. However, I do have an issue with the > idea of finding a single syslog corresponding to the netns for > a hypothetical printk in iptables. > > What happens with: > > /* in init_syslog_ns */ > clone(CLONE_SYSLOG) /* syslog_ns 1 */ > clone(CLONE_SYSLOG) /* syslog_ns 2 */ > <do something with iptables in the netns which triggers a printk> > > Even though that same printk is relevant to three "syslogs", it'll > only go to one, correct? If so, my feeling is that nsprintk > shouldn't take a syslog_ns directly. It should take some other > form of namespace and then write to the syslog of all the > nsproxies which share that namespace (a netns in this case).
Could do that - but I think it'd be fair to just keep track of a single netns->syslog_ns, namely the one which corresponded to the netns when netns was created. Don't allow unshare of syslog_ns, only clone. That ensures that the init task in a container will always be tied to the same net, pid, and syslog namespaces, giving us a point of sanity. -serge _______________________________________________ Containers mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
