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

2019-08-14 Thread Reindl Harald


Am 14.08.19 um 14:59 schrieb Ulrich Windl:
 Reindl Harald  schrieb am 14.08.2019 um 12:22 in
> Nachricht <13150bf2-e0c9-063a-9026-ac95c1fda...@thelounge.net>:
>>
>> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
>> Michael Chapman  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
> 
> Then why care about "junk on the /run/systemd/private socket."?

to avoid when people like you doing strange stuff coming here to blame
systemd as you did often enough in the past months
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-08-14 Thread Ulrich Windl
>>> Reindl Harald  schrieb am 14.08.2019 um 12:22 in
Nachricht <13150bf2-e0c9-063a-9026-ac95c1fda...@thelounge.net>:

> 
> Am 14.08.19 um 12:10 schrieb Ulrich Windl:
> Michael Chapman  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

Then why care about "junk on the /run/systemd/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 
> An: Zbigniew J??drzejewski-Szmek 
> Kopie (CC): systemd-devel@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
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel