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

Reindl Harald h.reindl at thelounge.net
Wed Aug 14 10:22:24 UTC 2019



Am 14.08.19 um 12:10 schrieb Ulrich Windl:
>>>> Michael Chapman <mike at very.puzzling.org> schrieb am 14.08.2019 um 11:47 in
>> That's all true, but the thing we need to check here is that systemd 
>> correctly handles junk on the /run/systemd/private socket. The change on 
>> the systemctl side certainly tries to prevent incorrect data being sent 
>> down the socket -- though it looks like there's several ways in which 
>> fd_move_above_stdio() can fail, so this isn't foolproof -- but we need to 
>> ensure that some _malicious_ client can't DoS systemd.
> 
> I don't want to contradict in principle, but doesn't "private socket" mean it's intended to be used by systemd only? Of course being root allows you to use any socket...

may is ask you to read the thread you are responding to?
nobody is touching the private socket

-------- Weitergeleitete Nachricht --------
Betreff: Re: [systemd-devel] systemd's connections to /run/systemd/private ?
Datum: Tue, 13 Aug 2019 17:50:56 -0400
Von: Brian Reichert <reichert at numachi.com>
An: Zbigniew J??drzejewski-Szmek <zbyszek at in.waw.pl>
Kopie (CC): systemd-devel at lists.freedesktop.org
This is sufficient to reproduce the effect of increasing the number
of file descriptors open to /run/systemd/private; at least, on my
box, in it's current state:

  sh -c 'exec 1>&-; /usr/bin/systemctl status ntpd.service'

We have cronjob that closes STDOUT, remaps STDERR to a log file,
and runs this systemctl command.  In my environment, this one-liner
will cause that FD count to go up by, 100% reproducible


More information about the systemd-devel mailing list