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. All we need to establish is whether that bug still exists in the current version of systemd. _Even if_ it isn't a security issue, having one fewer bugs is a good thing. _______________________________________________ systemd-devel mailing list email@example.com https://lists.freedesktop.org/mailman/listinfo/systemd-devel