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

[Michael Chapman <mike@xxxxxxxxxxxxxxxxx>]

On Wed, 14 Aug 2019, Lennart Poettering wrote:
> Quite frankly, invoking generic UNIX programs with fds < 3 closed is a
> really bad idea in general. That systemctl nowadays is particularly
> careful and deals with situations like that is not an invitation to
> actually invoke things like this. After all UNIX guarantees that
> open() (and the other calls that allocate an fd) allocated the lowest
> available one, hence they will necessarily step into
> stdin/stdout/stderr territory when invoked with any of those fds
> closed.
> 
> Hence: your code that closes fd1 like this is simply buggy. Don't do
> that, you are shooting yourself in the foot. And even if newer
> systemctl will handle cases like this more gracefully pretty much any
> other tool you might call will break in some form or another too,
> since a simple printf() will already spill into the wrong fds in that
> case.
> 
> Lennart

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