lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 8 Aug 2013 19:13:20 +0800
From:	Rui Xiang <rui.xiang@...wei.com>
To:	Gao feng <gaofeng@...fujitsu.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	<containers@...ts.linux-foundation.org>,
	<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
	<netfilter-devel@...r.kernel.org>, <serge.hallyn@...ntu.com>,
	<akpm@...ux-foundation.org>, <guz.fnst@...fujitsu.com>,
	<libo.chen@...wei.com>
Subject: Re: [PATCH v3 00/11] Add namespace support for syslog

On 2013/8/8 9:37, Gao feng wrote:
> On 08/07/2013 03:55 PM, Eric W. Biederman wrote:
>>
>> Since this still has not been addressed.  I am going to repeat Andrews
>> objection again.
>>
>> Isn't there a better way to get iptables information out than to use
>> syslog.  I did not have time to follow up on that but it did appear that
>> someone did have a better way to get the information out.
>>
>> Essentially the argument against this goes.  The kernel logging facility
>> is really not a particularly good tool to be using for anything other
>> than kernel debugging information, and there appear to be no substantial
>> uses for a separate syslog that should not be done in other ways.
> 
> containerizing syslog is not only for iptables, it also isolates the /dev/kmsg,
> /proc/kmsg, syslog(2)... user space tools in container may use this interface
> to read/generate syslog.
> 
> But I don't know how important/urgent this containerizing syslog work is,
> Rui Xiang, can you find an important/popular user space tool which uses this
> interfaces to generate kernel syslog?
> 

There are some other cases. Some warnings (bad mount options for tmpfs,
bad uid owner for many of them, etc) emerged in the container should
be exported to the container. Some belong on the host - if they show 
a corrupt superblock which may indicate an attempt by the container 
to crash the kernel. Like these, Kernel will print out warnings when 
userspace in container uses a deprecated something or other, and these
logs should be invisible and specific for current container.

I can't say this work is terribly compelling and important, but the 
impact may be obvious, IMO.


Thanks.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ