[systemd-devel] [PATCH] [RFC] [WIP] [kdbus] Attempt to recursively pass fd

[David Herrmann]

Hi

On Mon, Sep 15, 2014 at 11:53 PM, Daniel Mack <daniel at zonque.org> wrote:
> We might eventually allow this once we have a generic GC implementation
> for file descriptors (currently, there's only one, and that one only
> works for unix domain sockets). For now, we'll also need something that
> disallows passing kdbus handles over UDS.

The patch looks good. But I doubt we can fix this via a GC
implementation. I mean, there is no natural way to limit the recursion
level. If we recursively open an FD and queue the previous one into
it, we end up eating all kernel memory, but *all* FDs are still
retrievable! If we stop at like 10k FDs, you can still recursively
read all the queued FDs again, one per FD.

What I'm saying is, if we allow queuing kdbus FDs on kdbus, we need a
fixed recursion level or we have to account the user for the
underlying file even if they close it.

The fixed recursion level for unix sockets is not reliable, though. If
you look at the kernel patch, you see they only reset the recursion
level if the queue is emptied, not if the offending messaged is read.
That is, if you queue a message with recursion-level 4, then one
without any FD, but only the first message is read (that is, the real
recursion level is 0 now), you cannot queue this FD anywhere else. The
effective recursion level is still 4, as is only reset if that
non-offending message is read, too.
They had to do this, as computing the real recursion level is not
doable in O(1), but O(n) (n is queue-length) and they cannot break
backwards-compatibility.

So I think your kdbus patch is the way to go. And if we every want to
allow passing kdbus over kdbus, I'd vote for a recursion level "1".
That is, we only allow passing kdbus messages with an empty queue.

Thanks
David