[systemd-devel] systemd's connections to /run/systemd/private ?

[Lennart Poettering]

On Mi, 14.08.19 22:36, Michael Chapman (mike at very.puzzling.org) wrote:

> On Wed, 14 Aug 2019, Lennart Poettering wrote:
> > Well, a D-Bus connection can remain open indefinitely, and may even
> > have incomplete "half" messages queued in them as long as the client
> > desires. After the initial authentication is done, clients may thus
> > take up resources as long as they want, this is by design of dbus
> > really, and is different from HTTP for example, where connections
> > usually have a time-out applied. dbus doesn't know timeouts for
> > established connections. It knows them for the authentication phase,
> > and it knows them for method calls that are flight, but it does not
> > know them for the mere existance of an established connection.
>
> I'm sure it's not in the design of DBus that clients can continue to
> consume those resources after they've disconnected.
>
> > PID 1 authenticates clients of the private connection simply by making
> > the socket for it inaccessible to anyone who is not privileged. Due to
> > that it gets away with not doing any further per-user accounting,
> > because it knows the clients are all privileged anyway.
> >
> > So, yes, it would be good if we could protect us from any form of
> > misuse, but basically, if you have a root client that misbehaves you
> > have too accept that...
>
> I understand all that. Nevertheless, Brian identified a bug: after
> receiving certain data on its private socket, the systemd process can leak
> a file descriptor.

Can it? Did I miss something? If the client closes the client side of
the socket, but PID 1 would keep the server side of it open anyway,
then that would be a bug indeed. But my understanding was that the
client side stays pinned?

Lennart

--
Lennart Poettering, Berlin