max connections per control group (cgroup)

[Lennart Poettering]

On Thu, 14.08.14 13:04, Alban Crequy (alban.crequy at collabora.co.uk) wrote:

> 
> On Wed, 13 Aug 2014 19:06:42 +0200
> Lennart Poettering <mzqohf at 0pointer.de> wrote:
> 
> > On Wed, 06.08.14 15:16, Alban Crequy (alban.crequy at collabora.co.uk)
> > wrote:
> > 
> > > Hi,
> > > 
> > > In order to make dbus-daemon more resistant against
> > > denial-of-service issues, I implemented a new limit that could be
> > > added in the configuration: <limit
> > > name="max_connections_per_cgroup">16</limit>
> > 
> > Currently there's no way to racefreely acquire the cgroup path
> > really. While acquiring it racefully is OK for purely informational
> > purposes it sounds weird actually binding policy to it...
> 
> I'm not sure I understand the race correctly:
> 
> sd_pid_get_unit() reads /proc/<pid>/cgroup in a similar way to my
> patches and it finds the line with name=systemd. Is there something
> in sd_pid_get_unit() which makes it race-free?

No, that's a misunderstanding. sd_pid_get_unit() is doing exactly what
your patch does: just read /proc/pid/cgroup and parse it. It's
vulnerable to the exact same races.

The race is basically: somebody connects to the bus and quickly drops
off again, and now you know the PID but cannot make sense of it, because
the client is already gone.

But thinking about this, this is probably not actually a problem for the
dbus case, since the authentication is synchronous, and dbus hence
always gets a chance to read the path and the race hence goes
away. Sorry for the confusion.

> By the way, are sd_pid_get_unit() / sd_pid_get_user_unit() used
> somewhere for binding policy so far? I'm wondering if the parsing is
> safe: http://thread.gmane.org/gmane.linux.kernel.cgroups/11676

No, it's used purely informational so far.

Ah yupp, that sounds like a real kernel bug indeed.

Lennart

-- 
Lennart Poettering, Red Hat