Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Fri, 16 Aug 2019, Uoti Urpala wrote: > On Thu, 2019-08-15 at 20:36 +1000, Michael Chapman wrote: > > With systemd 239 I was unable to cause an fd leak this way. > > > > Still, I would feel more comfortable if I could find a commit that > > definitely fixed the problem. All of these experiments are just > > circumstantial evidence. > > 5ae37ad833583e6c1c7765767b7f8360afca3b07 > sd-bus: when attached to an sd-event loop, disconnect on processing errors Ah, nice. So since systemd v237. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Thu, 2019-08-15 at 20:36 +1000, Michael Chapman wrote: > With systemd 239 I was unable to cause an fd leak this way. > > Still, I would feel more comfortable if I could find a commit that > definitely fixed the problem. All of these experiments are just > circumstantial evidence. 5ae37ad833583e6c1c7765767b7f8360afca3b07 sd-bus: when attached to an sd-event loop, disconnect on processing errors ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
On Thu, 15 Aug 2019, Lennart Poettering wrote:
> 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?
I was able to reproduce the bug on CentOS 7's systemd 219. That is, the
file descriptor in PID 1 was dropped from its epoll set without it
reaching EOF and without it being closed. Every time I ran Brian's command
PID 1 would leak another file descriptor.
I was unable to reproduce this on a later version of systemd, but that
_could_ just be because this later version of systemd side-steps the issue
by ensuring that systemctl doesn't use fd 1 for its socket.
I have some reason to believe the problem in PID 1 has been fixed though.
On CentOS 7 I was able to cause it to sometimes leak an fd simply by
sending random data to it:
# count-sockets() { ss -x | grep /run/systemd/private | wc -l; }
# inject-junk() { timeout 1s nc -U /run/systemd/private https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd's connections to /run/systemd/private ?
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
