On Mi, 14.08.19 22:36, Michael Chapman (m...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
