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

[Michael Chapman]

On Wed, 14 Aug 2019, Ulrich Windl wrote:
> >>> Michael Chapman <mike at very.puzzling.org> schrieb am 14.08.2019 um 11:47 in
> Nachricht <alpine.LFD.2.21.1908141941560.3528 at beren.home>:
> > 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.
> 
> Hi!
> 
> 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...
>
> I could imaging two things of torture testing:
> 1) send random data to the socket and see what happens.
> 2) vary valid messages randomly to see what happens

Any user can connect to it at least. systemd will drop the connection if 
it's from an unprivileged client. The question though is whether junk 
data still pending on that connection will cause systemd to leak the file 
descriptor.

I think we'd need to fully understand why the problem occurred on older 
systemd versions to be able to answer that. Maybe that problem has been 
fixed.