Re: [systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

2014-04-10 Thread Tollef Fog Heen
]] Lennart Poettering 

 Maybe we shouldn't bother too much with making this one-time. Maybe
 instead we should print it all the time, but simply at debug log level,
 so that this isnt too visible...

It's just when starting services, isn't it?  I think we should log it
each time at a visible priority, since it can have security
implications.  If people have a problem with that spamming them, turn
off PrivateNetwork in their service files or make sure their kernel has
the support.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

2014-04-10 Thread Thomas Bächler
Am 10.04.2014 03:35, schrieb Lennart Poettering:
 Simply try:
   int func(...) {
  static bool network_namespace_warning = false;
  ...

  if (!network_namespace_warning) {
  network_namespace_warning = true;
   log_warn(...);
  }
   }

 Zbyszek
 
 Hmm, so actually this is more complex than this, since the network
 namespace stuff is done after we fork() before we exec() in the child
 process. That means having this as static variable won't help, since you
 could only set the copy, never the variable in the parent.

So, why not issue the warning while parsing the configuration, i.e.
during daemon startup or reload?




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

2014-04-10 Thread Colin Guthrie
'Twas brillig, and Tollef Fog Heen at 10/04/14 07:53 did gyre and gimble:
 ]] Lennart Poettering 
 
 Maybe we shouldn't bother too much with making this one-time. Maybe
 instead we should print it all the time, but simply at debug log level,
 so that this isnt too visible...
 
 It's just when starting services, isn't it?  I think we should log it
 each time at a visible priority, since it can have security
 implications.  If people have a problem with that spamming them, turn
 off PrivateNetwork in their service files or make sure their kernel has
 the support.

Yeah I was about to make the same comment, but instead: +1. Some people
might *think* they are more secure than they really are. Visible logging
on each service start shouldn't be too horrible or spammy IMO.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

2014-04-10 Thread Lennart Poettering
On Thu, 10.04.14 10:21, Thomas Bächler (tho...@archlinux.org) wrote:

 Am 10.04.2014 03:35, schrieb Lennart Poettering:
  Simply try:
int func(...) {
   static bool network_namespace_warning = false;
   ...
 
   if (!network_namespace_warning) {
   network_namespace_warning = true;
  log_warn(...);
   }
}
 
  Zbyszek
  
  Hmm, so actually this is more complex than this, since the network
  namespace stuff is done after we fork() before we exec() in the child
  process. That means having this as static variable won't help, since you
  could only set the copy, never the variable in the parent.
 
 So, why not issue the warning while parsing the configuration, i.e.
 during daemon startup or reload?

Yeah, I thought about that too, but I couldn't think about a nice way to
detect this. However, now thinking about this again I think it might be
OK to do an access(/proc/self/ns/net, F_OK) should suffice. The
/proc/self/ns feature is newer than net namespaces, but that shouldn't
matter because to my knowledge both where available in 3.0 and we don't
support anything older anymore.

So, yeah, let's do this!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

2014-04-09 Thread Tom Gundersen
On Mon, Mar 31, 2014 at 8:28 PM, Mike Gilbert flop...@gentoo.org wrote:
 Several units now utilize the PrivateNetwork parameter, which requires
 network namespace support.

Applied. Thanks!

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

2014-04-09 Thread Lennart Poettering
On Wed, 09.04.14 11:21, Tom Gundersen (t...@jklm.no) wrote:

 
 On Mon, Mar 31, 2014 at 8:28 PM, Mike Gilbert flop...@gentoo.org wrote:
  Several units now utilize the PrivateNetwork parameter, which requires
  network namespace support.

BTW, this really sounds like something where we should have graceful
degradation: if network namespaces are missing we should probably simply
ignore PrivateNetwork= (maybe print a one-time warning to syslog, just
to mentioned this), and proceed without them. After all this is a
feature that just takes away features, and doesn't add any, thus simply
ignoring it should be safe.

I'd be happy to merge a patch which implements such a scheme to support
kernels with a more limited feature set.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

2014-04-09 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Apr 09, 2014 at 07:35:15PM -0400, Mike Gilbert wrote:
 On Wed, Apr 9, 2014 at 12:32 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Wed, 09.04.14 11:21, Tom Gundersen (t...@jklm.no) wrote:
 
 
  On Mon, Mar 31, 2014 at 8:28 PM, Mike Gilbert flop...@gentoo.org wrote:
   Several units now utilize the PrivateNetwork parameter, which requires
   network namespace support.
 
  BTW, this really sounds like something where we should have graceful
  degradation: if network namespaces are missing we should probably simply
  ignore PrivateNetwork= (maybe print a one-time warning to syslog, just
  to mentioned this), and proceed without them. After all this is a
  feature that just takes away features, and doesn't add any, thus simply
  ignoring it should be safe.
 
  I'd be happy to merge a patch which implements such a scheme to support
  kernels with a more limited feature set.
 
 
 Are there any examples of how to implement a one-time warning for
 this sort of thing?
Not in systemd, I think.

Simply try:
  int func(...) {
 static bool network_namespace_warning = false;
 ...

 if (!network_namespace_warning) {
 network_namespace_warning = true;
 log_warn(...);
 }
  }

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

2014-03-31 Thread Mike Gilbert
Several units now utilize the PrivateNetwork parameter, which requires
network namespace support.
---
 README | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/README b/README
index fc13e10..cecbcbf 100644
--- a/README
+++ b/README
@@ -70,6 +70,9 @@ REQUIREMENTS:
 create additional symlinks in /dev/disk/ and /dev/tape:
   CONFIG_BLK_DEV_BSG
 
+Required for PrivateNetwork in service units:
+  CONFIG_NET_NS
+
 Optional but strongly recommended:
   CONFIG_IPV6
   CONFIG_AUTOFS4_FS
-- 
1.9.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel