Containerize syslog
Subsystems (2)
cover Containerize syslog
From: Xiang Rui <[email protected]>
In Serge's patch (http://lwn.net/Articles/525629/), syslog_namespace was tied to a user namespace. We add syslog_ns tied to nsproxy instead, and implement ns_printk in ip_table context.
We add syslog_namespace as a part of nsproxy, and a new flag CLONE_SYSLOG to unshare syslog area.
In syslog_namespace, some necessary identifiers for handling syslog buf are contained. When one container creates a new syslog namespace,containerized buf will be allocated to store log ownned this container. Containerized identifiers such as log_first_seq instead of global variable only affect their own buf.The buf will not be free until syslog_namespace is destructed by host.
Printk should be re-implimented because log buf is isolated into syslog_ns. The function include printk, /dev/kmsg, do_syslog and kmsg_dump should be realized in container. So, to make these funtions available in container, a parameter syslog_ns is necessory for their interfaces.
For container context, the value syslog namespace is reasonable if we use current method to get syslog_ns when using iptable. Because the log info belong to each containers will be printed in host.
We add a pointer in net namespace, and use it to track the syslog_ns which was created when the log was generated in container. Then add ns_printk to provide a new interface while using syslog_ns.
This patchset is based on the develop tree of net branch
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git.
Libo Chen (3):
printk: modify printk interface for syslog_namespace
printk: add ns_printk for specific syslog_ns
printk: use ns_printk in iptable context
Xiang Rui (2):
Syslog_ns: add syslog_namespace struct and API
Syslog_ns: add CLONE_NEWSYSLOG and create syslog_ns when copying
process
drivers/base/core.c | 4 +- include/linux/nsproxy.h | 2 + include/linux/printk.h | 5 +- include/linux/syslog_namespace.h | 98 ++++++ include/net/net_namespace.h | 7 +- include/net/netfilter/xt_log.h | 7 +- include/uapi/linux/sched.h | 3 +- init/Kconfig | 7 + kernel/Makefile | 1 + kernel/nsproxy.c | 19 +- kernel/printk.c | 646 ++++++++++++++++++++++++-------------- kernel/syslog_namespace.c | 65 ++++ net/core/net_namespace.c | 12 +- net/netfilter/xt_LOG.c | 4 +- 14 files changed, 623 insertions(+), 257 deletions(-) create mode 100644 include/linux/syslog_namespace.h create mode 100644 kernel/syslog_namespace.c
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 20 lines · Rui Xiang
From: Xiang Rui <[email protected]>
In Serge's patch (http://lwn.net/Articles/525629/),
syslog_namespacewas tied to a user namespace. We addsyslog_nstied to nsproxy instead, and implementns_printkinip_tablecontext.We add
syslog_namespaceas a part of nsproxy, and a new flagCLONE_SYSLOGto unshare syslog area.In
syslog_namespace, some necessary identifiers for handling syslog buf are contained. When one container creates a new syslog namespace,containerized buf will be allocated to store log ownned this container. Containerized identifiers such aslog_first_seqinstead of global variable only affect their own buf.The buf will not be free untilsyslog_namespaceis destructed by host.Printk should be re-implimented because log buf is isolated into
syslog_ns. The function include printk,/dev/kmsg,do_syslogandkmsg_dumpshould be realized in container. So, to make these funtions available in container, a parametersyslog_nsis necessory for their interfaces.
Quoted 7 lines
For container context, the value syslog namespace is reasonable if we use current method to get
syslog_nswhen using iptable. Because the log info belong to each containers will be printed in host.We add a pointer in net namespace, and use it to track the
syslog_nswhich was created when the log was generated in container. Then addns_printkto provide a new interface while usingsyslog_ns.
It occurs to me that calling this a syslog namespace is a misnomer. Syslog in general uses unix domain sockets. This is about the linux kernel specific kernel log interface that tends to be put in syslog.
Are there any kernel print statements besides networking stack printks that we want to move to show up in a new "kernel log" namespace?
For the kernel generated pieces of information that are interesting (and their don't seem to be many of those) would we be better off using another kernel method that is already per namespace. Something like netlink.
Eric
A message that is not in the archive (sent off-list or not yet received): 874nklkjjm.fsf-aS9lmoZGLiVWk0Htik3J/[email protected]
Quoted 2 lines · On Mon, 19 Nov 2012 01:51:09 -0800 ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]…
Are there any kernel print statements besides networking stack printks that we want to move to show up in a new "kernel log" namespace?
That's a good question, and afaict it remains unanswered.
As so often happens, this patchset's changelogs forgot to describe the reason for the existence of this patchset. Via a bit of lwn reading and my awesome telepathic skills, I divine that something in networking is using syslog for kernel->userspace communications.
wtf?
Wouldn't it be better to just stop doing that, and to implement a respectable and reliable kernel->userspace messaging scheme?
And leave syslog alone - it's a crude low-level thing for random unexpected things which operators might want to know about.
A message that is not in the archive (sent off-list or not yet received): 20121207010355.c809b3f7.akpm-de/[email protected]
Quoted 6 lines · Andrew Morton
Quoted 2 lines · On Mon, 19 Nov 2012 01:51:09 -0800 ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]…
Are there any kernel print statements besides networking stack printks that we want to move to show up in a new "kernel log" namespace?
That's a good question, and afaict it remains unanswered.
There are some other (not *terribly* compelling) cases. For instance selinux hooks, if you say mount an fs without xattr support or with unsupported options, will printk a warning. Things like stat.c and capabilities and syslog print out warnings when userspace uses a deprecated somethingorother - old stat syscall or sys_syslog without CAP_SYSLOG. That should go to the container. Filesystems may give warnings (bad mount options for tmpfs, bad uid owner for many of them, etc) which belong in the container. Obviously some belong on the host - if they show a corrupt superblock which may indicate an attempt by the container to crash the kernel.
Quoted 2 lines
As so often happens, this patchset's changelogs forgot to describe the reason for the existence of this patchset. Via a bit of lwn reading
Not as a separate justification admittedly, but the description was meant to explain it: right now /dev/kmsg and sys_syslog are not safe and useful in a container; syslog messages from host and containers can be confusingly intermixed; and helpful printks are not seen in the container.
Quoted 4 lines
and my awesome telepathic skills, I divine that something in networking is using syslog for
kernel->userspacecommunications.wtf?
Well, syslog is the kernel->userspace channel of last resort.
Quoted 2 lines
Wouldn't it be better to just stop doing that, and to implement a respectable and reliable
kernel->userspacemessaging scheme?
Convenience functions on top of netlink?
Quoted 2 lines
And leave syslog alone - it's a crude low-level thing for random unexpected things which operators might want to know about.
That sentence is a result of not calling a container admin an operator. I can't argue it because I'm not sure whether to agree with that classification.
-serge
Quoted 38 lines · Serge Hallyn
Quoted 6 lines · Andrew Morton
Quoted 2 lines · On Mon, 19 Nov 2012 01:51:09 -0800 ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]…
Are there any kernel print statements besides networking stack printks that we want to move to show up in a new "kernel log" namespace?
That's a good question, and afaict it remains unanswered.
There are some other (not *terribly* compelling) cases. For instance selinux hooks, if you say mount an fs without xattr support or with unsupported options, will printk a warning. Things like
stat.cand capabilities and syslog print out warnings when userspace uses a deprecated somethingorother - old stat syscall orsys_syslogwithoutCAP_SYSLOG. That should go to the container. Filesystems may give warnings (bad mount options for tmpfs, bad uid owner for many of them, etc) which belong in the container. Obviously some belong on the host - if they show a corrupt superblock which may indicate an attempt by the container to crash the kernel.Quoted 2 lines
As so often happens, this patchset's changelogs forgot to describe the reason for the existence of this patchset. Via a bit of lwn reading
Not as a separate justification admittedly, but the description was meant to explain it: right now
/dev/kmsgandsys_syslogare not safe and useful in a container; syslog messages from host and containers can be confusingly intermixed; and helpful printks are not seen in the container.Quoted 4 lines
and my awesome telepathic skills, I divine that something in networking is using syslog for
kernel->userspacecommunications.wtf?
Well, syslog is the
kernel->userspacechannel of last resort.Quoted 2 lines
Wouldn't it be better to just stop doing that, and to implement a respectable and reliable
kernel->userspacemessaging scheme?
Quoted 9 lines
Convenience functions on top of netlink?
Quoted 2 lines
And leave syslog alone - it's a crude low-level thing for random unexpected things which operators might want to know about.
That sentence is a result of not calling a container admin an operator. I can't argue it because I'm not sure whether to agree with that classification.
I keep asking myself if it isn't the case of forwarding to a container all messages printed in process context. That will obviously exclude all messages resulting from kthreads - that will always be in the initial namespace anyway, interrupts, etc. There is no harm, for instance, in delivering the same message twice: one to the container, and the other to the host system.
Isn't it natural that if the kernel printed something on behalf of a process, whoever is the admin of the machine that process lives on should see what it is about?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 6 lines · Glauber Costa
I keep asking myself if it isn't the case of forwarding to a container all messages printed in process context. That will obviously exclude all messages resulting from kthreads - that will always be in the initial namespace anyway, interrupts, etc. There is no harm, for instance, in delivering the same message twice: one to the container, and the other to the host system.
Except that there is harm in double printing. One of the better justifications for doing something with the kernel log is that it is possible to overflow the kernel log with operations performed exclusively in a container.
I do think the idea of process context printks going to the current container one worth playing with.
Eric
A message that is not in the archive (sent off-list or not yet received): 87r4n1buuw.fsf-aS9lmoZGLiVWk0Htik3J/[email protected]
Quoted 9 lines · Eric W. Biederman
Quoted 6 lines · Glauber Costa
I keep asking myself if it isn't the case of forwarding to a container all messages printed in process context. That will obviously exclude all messages resulting from kthreads - that will always be in the initial namespace anyway, interrupts, etc. There is no harm, for instance, in delivering the same message twice: one to the container, and the other to the host system.
Quoted 5 lines
Except that there is harm in double printing. One of the better justifications for doing something with the kernel log is that it is possible to overflow the kernel log with operations performed exclusively in a container.
I don't agree with you here.
If we are double printing, we are using up more memory, but we also have an extra buffer anyway. The messages are print on behalf of the user, but still, by the kernel.
So one of the following will necessarily hold:
1) There is no way that the process can overflow the main log, and as a consequence, the container log, that has less messages than it.
2) The process will overflow the main log. But since we are not printing anything extra to the main log compared to the scenario in which the process lives in the main namespace, this would already be a problem independent of namespaces. And needs to be fixed.
IOW, double printing should not print anything *extra* to the main log. It just prints to the container log, and leaves a copy to the box admin to see. I think it is very reasonable to imagine that the main admin would like to see anything the kernel has to tell him about the box.
Quoted 3 lines
I do think the idea of process context printks going to the current container one worth playing with.
It still leaves the problem of prinkts outside process context that should go to a namespace open. But it is easy to extend this idea to do both.
Quoted 9 lines · Eric W. Biederman
Quoted 6 lines · Glauber Costa
I keep asking myself if it isn't the case of forwarding to a container all messages printed in process context. That will obviously exclude all messages resulting from kthreads - that will always be in the initial namespace anyway, interrupts, etc. There is no harm, for instance, in delivering the same message twice: one to the container, and the other to the host system.
Quoted 5 lines
Except that there is harm in double printing. One of the better justifications for doing something with the kernel log is that it is possible to overflow the kernel log with operations performed exclusively in a container.
I don't agree with you here.
If we are double printing, we are using up more memory, but we also have an extra buffer anyway. The messages are print on behalf of the user, but still, by the kernel.
So one of the following will necessarily hold:
1) There is no way that the process can overflow the main log, and as a consequence, the container log, that has less messages than it.
2) The process will overflow the main log. But since we are not printing anything extra to the main log compared to the scenario in which the process lives in the main namespace, this would already be a problem independent of namespaces. And needs to be fixed.
IOW, double printing should not print anything *extra* to the main log. It just prints to the container log, and leaves a copy to the box admin to see. I think it is very reasonable to imagine that the main admin would like to see anything the kernel has to tell him about the box.
Quoted 3 lines
I do think the idea of process context printks going to the current container one worth playing with.
It still leaves the problem of prinkts outside process context that should go to a namespace open. But it is easy to extend this idea to do both.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 23 lines · Glauber Costa
Quoted 9 lines · Eric W. Biederman
Quoted 6 lines · Glauber Costa
I keep asking myself if it isn't the case of forwarding to a container all messages printed in process context. That will obviously exclude all messages resulting from kthreads - that will always be in the initial namespace anyway, interrupts, etc. There is no harm, for instance, in delivering the same message twice: one to the container, and the other to the host system.
Quoted 5 lines
Except that there is harm in double printing. One of the better justifications for doing something with the kernel log is that it is possible to overflow the kernel log with operations performed exclusively in a container.
I don't agree with you here.
If we are double printing, we are using up more memory, but we also have an extra buffer anyway. The messages are print on behalf of the user, but still, by the kernel.
So one of the following will necessarily hold:
Quoted 7 lines
1) There is no way that the process can overflow the main log, and as a consequence, the container log, that has less messages than it.
2) The process will overflow the main log. But since we are not printing anything extra to the main log compared to the scenario in which the process lives in the main namespace, this would already be a problem independent of namespaces. And needs to be fixed.
Well mounts, brining network interfaces up and down, running packets through our own choice of firewall rules, possibly enabling debug messages on network interfaces has the potential to create messages we aren't seeing today.
Quoted 4 lines
IOW, double printing should not print anything *extra* to the main log. It just prints to the container log, and leaves a copy to the box admin to see. I think it is very reasonable to imagine that the main admin would like to see anything the kernel has to tell him about the box.
The only reason that I have seen for doing anything with printks is because we are generating messages that would not be generated in a non-container environment. At which point double printing is scary because it allows a container user to flood the kernel log ring buffer and suppress interesting messages.
Quoted 7 lines
Quoted 3 lines
I do think the idea of process context printks going to the current container one worth playing with.
It still leaves the problem of prinkts outside process context that should go to a namespace open. But it is easy to extend this idea to do both.
Hmm. For printks from process context I think I can see a point where double printing makes sense, because that is a rather indiscriminate grab of printk messages.
Eric
Quoted 33 lines · Eric W. Biederman
Quoted 23 lines · Glauber Costa
Quoted 9 lines · Eric W. Biederman
Quoted 6 lines · Glauber Costa
I keep asking myself if it isn't the case of forwarding to a container all messages printed in process context. That will obviously exclude all messages resulting from kthreads - that will always be in the initial namespace anyway, interrupts, etc. There is no harm, for instance, in delivering the same message twice: one to the container, and the other to the host system.
Quoted 5 lines
Except that there is harm in double printing. One of the better justifications for doing something with the kernel log is that it is possible to overflow the kernel log with operations performed exclusively in a container.
I don't agree with you here.
If we are double printing, we are using up more memory, but we also have an extra buffer anyway. The messages are print on behalf of the user, but still, by the kernel.
So one of the following will necessarily hold:
Quoted 7 lines
1) There is no way that the process can overflow the main log, and as a consequence, the container log, that has less messages than it.
2) The process will overflow the main log. But since we are not printing anything extra to the main log compared to the scenario in which the process lives in the main namespace, this would already be a problem independent of namespaces. And needs to be fixed.
Quoted 5 lines
Well mounts, brining network interfaces up and down, running packets through our own choice of firewall rules, possibly enabling debug messages on network interfaces has the potential to create messages we aren't seeing today.
There are two kinds of messages: the ones that would be print anyway if you were not running in an ns, which we have no reason to fear, and the ones that only exist because we wrote the code for them, due to ns support. They are no different from writing a new fs support, driver, etc. Any new functionality can print new messages, and we have to be sure they won't fill the log. We write that code, so it is on us to make sure the messages are being print in a reasonable rate.
This should be true for all messages running in process context. It is either that, or we have a bug and we relying on a specific clone flag to protect us against the buffer overrun.
Quoted 15 lines
Quoted 4 lines
IOW, double printing should not print anything *extra* to the main log. It just prints to the container log, and leaves a copy to the box admin to see. I think it is very reasonable to imagine that the main admin would like to see anything the kernel has to tell him about the box.
The only reason that I have seen for doing anything with printks is because we are generating messages that would not be generated in a non-container environment. At which point double printing is scary because it allows a container user to flood the kernel log ring buffer and suppress interesting messages.
Quoted 4 lines
Quoted 3 lines
I do think the idea of process context printks going to the current container one worth playing with.
Quoted 8 lines
Quoted 3 lines
It still leaves the problem of prinkts outside process context that should go to a namespace open. But it is easy to extend this idea to do both.
Hmm. For printks from process context I think I can see a point where double printing makes sense, because that is a rather indiscriminate grab of printk messages.
exactly. What I have in mind this whole time, is that if you are printing a message of interest of the container admin, it is *very likely* also of interest of the box admin, specially if it indicates something going wrong. Maybe what goes and does not go to the main buffer can be determined by the log level of each buffer. But still, I think that just hiding them from the box admin may not exactly be what we want.
Cheers
A message that is not in the archive (sent off-list or not yet received): [email protected]
This conversation is really debating the wrong question.
The fundamental question is can we modify the kernel such that containers don't care about anything that goes into the kernel log.
The fundamental question leads to the question what functionality that is logged to the kernel log must we see in containers.
Serge has a collected a lot of cases and it seems reasonable to assume that we will find those cases that must show up in a container or require huge userspace reworking.
These messages that must show up in a container (or break userspace) are messages that already exist today. These messages quite likely are specific to the container itself and I don't think we will need to double log them.
But the first step of the process is to find the kernel messages that if we don't log to user space via the kernel log will break user space.
Once we have found those messages and the cases in which there are no work-arounds we can refine the design with nice to haves.
But this conversation really needs to be about which messages must we deliver to userspace via the kernel log.
There are a lot of nice to haves messages out there. Mount failures, selinux failures etc. Some of those have a pretty compelling case to be double logged.
I think for the compelling cases we won't want to doulbe log them, and those compelling cases need to drive the design.
The most compelling case I know of are firewall log messages that are logge by explicit user request when selected packets hit the local firewall. Those messages I definitely don't want to double log and those messages are most definitely not interesting to the operator of the machine. Those messages are only interesting to the admin who configured his firewall to log them.
We should look to see if there are alternatives to user configured firewall log messages that a system administratrator can use. If not we have our first compelling case for this functionality.
Eric
A message that is not in the archive (sent off-list or not yet received): 87txrs30ur.fsf-aS9lmoZGLiVWk0Htik3J/[email protected]
Quoted 33 lines · Eric W. Biederman
Quoted 23 lines · Glauber Costa
Quoted 9 lines · Eric W. Biederman
Quoted 6 lines · Glauber Costa
I keep asking myself if it isn't the case of forwarding to a container all messages printed in process context. That will obviously exclude all messages resulting from kthreads - that will always be in the initial namespace anyway, interrupts, etc. There is no harm, for instance, in delivering the same message twice: one to the container, and the other to the host system.
Quoted 5 lines
Except that there is harm in double printing. One of the better justifications for doing something with the kernel log is that it is possible to overflow the kernel log with operations performed exclusively in a container.
I don't agree with you here.
If we are double printing, we are using up more memory, but we also have an extra buffer anyway. The messages are print on behalf of the user, but still, by the kernel.
So one of the following will necessarily hold:
Quoted 7 lines
1) There is no way that the process can overflow the main log, and as a consequence, the container log, that has less messages than it.
2) The process will overflow the main log. But since we are not printing anything extra to the main log compared to the scenario in which the process lives in the main namespace, this would already be a problem independent of namespaces. And needs to be fixed.
Quoted 5 lines
Well mounts, brining network interfaces up and down, running packets through our own choice of firewall rules, possibly enabling debug messages on network interfaces has the potential to create messages we aren't seeing today.
There are two kinds of messages: the ones that would be print anyway if you were not running in an ns, which we have no reason to fear, and the ones that only exist because we wrote the code for them, due to ns support. They are no different from writing a new fs support, driver, etc. Any new functionality can print new messages, and we have to be sure they won't fill the log. We write that code, so it is on us to make sure the messages are being print in a reasonable rate.
This should be true for all messages running in process context. It is either that, or we have a bug and we relying on a specific clone flag to protect us against the buffer overrun.
Quoted 15 lines
Quoted 4 lines
IOW, double printing should not print anything *extra* to the main log. It just prints to the container log, and leaves a copy to the box admin to see. I think it is very reasonable to imagine that the main admin would like to see anything the kernel has to tell him about the box.
The only reason that I have seen for doing anything with printks is because we are generating messages that would not be generated in a non-container environment. At which point double printing is scary because it allows a container user to flood the kernel log ring buffer and suppress interesting messages.
Quoted 4 lines
Quoted 3 lines
I do think the idea of process context printks going to the current container one worth playing with.
Quoted 8 lines
Quoted 3 lines
It still leaves the problem of prinkts outside process context that should go to a namespace open. But it is easy to extend this idea to do both.
Hmm. For printks from process context I think I can see a point where double printing makes sense, because that is a rather indiscriminate grab of printk messages.
exactly. What I have in mind this whole time, is that if you are printing a message of interest of the container admin, it is *very likely* also of interest of the box admin, specially if it indicates something going wrong. Maybe what goes and does not go to the main buffer can be determined by the log level of each buffer. But still, I think that just hiding them from the box admin may not exactly be what we want.
Cheers
Quoted 3 lines · Serge Hallyn
Not as a separate justification admittedly, but the description was meant to explain it: right now
/dev/kmsgandsys_syslogare not safe and useful in a container;
The user namespace solves this the biggest practical problem, like it solves so many other problems of excessive privileges in a container.
Since these patches are still mostly in the design proof-of-concept/design phase I am inclined to see how getting a usable user namespace affects the situation on the ground.
But I do think there are issues to be solved in some fashion. We have the possibiloity of configuring firewall logging rules that are not
usable in containers. Similarly reasons for mount failures and number
of other cases go silent.
I think it makes some sense to change where we put things in the kernel log to solve these things but it also makes sense to ask the question is there a better solution. Hopefully a little more experience with these issues and time playing with ideas can make things clear.
Eric
Quoted 3 lines · Serge Hallyn
Not as a separate justification admittedly, but the description was meant to explain it: right now
/dev/kmsgandsys_syslogare not safe and useful in a container;
The user namespace solves this the biggest practical problem, like it solves so many other problems of excessive privileges in a container.
Since these patches are still mostly in the design proof-of-concept/design phase I am inclined to see how getting a usable user namespace affects the situation on the ground.
But I do think there are issues to be solved in some fashion. We have the possibiloity of configuring firewall logging rules that are not
usable in containers. Similarly reasons for mount failures and number
of other cases go silent.
I think it makes some sense to change where we put things in the kernel log to solve these things but it also makes sense to ask the question is there a better solution. Hopefully a little more experience with these issues and time playing with ideas can make things clear.
Eric
Quoted 5 lines · Rui Xiang
From: Xiang Rui <[email protected]>
In Serge's patch (http://lwn.net/Articles/525629/),
syslog_namespacewas tied to a user namespace. We addsyslog_nstied to nsproxy instead, and implementns_printkinip_tablecontext.
Since you say 'we', I'm just wondering, which project is this a part of?
Quoted 2 lines
We add
syslog_namespaceas a part of nsproxy, and a new flagCLONE_SYSLOGto unshare syslog area.
Thanks, looks like you save me the time of having to add some users of nsprintk :)
I understand that user namespaces aren't 100% usable yet, but looking long term, is there a reason to have the syslog namespace separate from user namespace?
thanks,
-serge
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Serge E. Hallyn
Quoted 5 lines · Rui Xiang
From: Xiang Rui <[email protected]>
In Serge's patch (http://lwn.net/Articles/525629/),
syslog_namespacewas tied to a user namespace. We addsyslog_nstied to nsproxy instead, and implementns_printkinip_tablecontext.Since you say 'we', I'm just wondering, which project is this a part of?
Hi,Serge
Thank you for your attention.
We may use container in our company, and one of the missing part we found is syslog isolation (though we require this feature or not is not sure at this moment), so we made this patchset.
Quoted 9 lines
Quoted 2 lines
We add
syslog_namespaceas a part of nsproxy, and a new flagCLONE_SYSLOGto unshare syslog area.Thanks, looks like you save me the time of having to add some users of nsprintk :)
I understand that user namespaces aren't 100% usable yet, but looking long term, is there a reason to have the syslog namespace separate from user namespace?
Actually we don't have strong preference. We'll think more about it. Hope we can make consensus with Eric.
Thanks,
Rui Xiang
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Rui Xiang
Quoted 3 lines · Serge E. Hallyn
I understand that user namespaces aren't 100% usable yet, but looking long term, is there a reason to have the syslog namespace separate from user namespace?
Actually we don't have strong preference. We'll think more about it. Hope we can make consensus with Eric.
I hope I am not hard to work with. My primary concern is reasonable looking code and good long term maintainable semantics.
I really don't care in which namespace where we file the kernel log statements.
I care much more about which kernel log print statements we want filed differently.
Eric
Quoted 8 lines · Rui Xiang
Quoted 3 lines · Serge E. Hallyn
I understand that user namespaces aren't 100% usable yet, but looking long term, is there a reason to have the syslog namespace separate from user namespace?
Actually we don't have strong preference. We'll think more about it. Hope we can make consensus with Eric.
I hope I am not hard to work with. My primary concern is reasonable looking code and good long term maintainable semantics.
I really don't care in which namespace where we file the kernel log statements.
I care much more about which kernel log print statements we want filed differently.
Eric