-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Simon,
On 03/16/16 15:52, Simon McVittie wrote: > On Wed, 16 Mar 2016 at 14:11:12 +0100, Harald Dunkel wrote: > >> How can I increase the timeout to enable booting a handful of LXC containers >> in parallel? > > Create /etc/dbus-1/system-local.conf containing: > > <busconfig> <limit name="auth_timeout">123456</limit> </busconfig> > > The value is in milliseconds, adjust as required. > I will try. > How many LXC containers are you booting, on what hardware, and what service > is connecting to the system bus and getting rejected? My test case is 31 containers on a quad core (+ht) Xeon E5420 CPU. The production machine is a 2 * 6core (+ht) Xeon E5-2630 running about 20 containers. On both hosts it can take 5 or 10 minutes until the last container gets its IP address via network (DHCP). The service that apparently cannot connect is sssd. The containers are started, but on some nss is broken. > It would be better if you could avoid having to raise this limit too high. > The limit was added to resolve CVE-2014-3639, a denial of service > vulnerability: with a high or infinite authentication timeout, a uid (let's > say alice) can prevent another uid (let's say bob) from connecting to the > system bus, by opening enough connections to fill all the unauthenticated > connection slots (by default 64 connections) and not making any attempt to > authenticate themselves. Wouldn't you agree that a high watermark on the number of used connection slots to enable the timeout restriction would have been a better choice? > > You might be able to mitigate this by increasing the > max_incomplete_connections limit. By default the system dbus-daemon will > support up to 64 incomplete (unauthenticated) connections, up to 256 > authenticated connections per uid (max_connections_per_user), and up to 2048 > authenticated > connections in total (max_completed_connections). > > In general we can't tell whose a connection is until it has authenticated, > but on Linux with the default system bus configuration we can, so in newer > upstream versions we might be able to mitigate this sort of thing by making > uid 0 immune to these limits. Would that solve this for you? > Probably its reasonable to ignore the timeout for uid0, but surely it will take some time till this change appears in a future Debian release. I am still struggling to replace the old Squeeze hosts nobody likes to give up. They worked too well. Thanx very much for your detailed description. This was very helpful. Regards Harri -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW6pk5AAoJEAqeKp5m04HLUEgH/A3pWE2K5R6n75KN4cdh5fBJ qvcVRiEA/rG29eKjbYNLaMsdIXmOq+oFHxngV+Mac98JbKwzHyWh5SrJNuxuZVYt 70GrL5jZNMnRGeK+zR5CvMAX8rhVgPYRCeRLgyqFJVDMhP3Dj3tGEYVk078PXROH Hu/WrkqRpm6CYMR8DzsyqIYl9tQnTPFE/YVDBwA4gH69IFD8VS5S43i7GthX1/mo Ls5j6KDSA53dTRAP1HtS0Yy75sl1aVYBYbUlkw+u9jRuzEhKAlj3lLHKh9iuDc0W xauM0jEk7Xj+i5mP+1JXzZBDsg/cArh+GzvUIr4dSb+dz1o4Iso3rykyIgYyFVg= =4RWX -----END PGP SIGNATURE-----
