Re: systemd's connections to /run/systemd/private ?

[Michael Chapman <mike@xxxxxxxxxxxxxxxxx>]

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
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel