[systemd-devel] [PATCH 4/4] core: lazy distribute for Distribute pools

[Zbigniew Jędrzejewski-Szmek]

On Sun, Nov 17, 2013 at 02:57:56PM -0800, Shawn Landden wrote:
> On Sun, Nov 17, 2013 at 2:28 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
> > On Sun, Nov 17, 2013 at 08:46:46PM +0100, Lennart Poettering wrote:
> >> On Sat, 16.11.13 13:18, Shawn Landden (shawn at churchofgit.com) wrote:
> >> >                          <varlistentry>
> >> > +                                <term><varname>LazyDistribute=</varname></term>
> >> > +                                <listitem><para>Takes an boolean
> >> > +                                value. If true, Distribute=n workers will not be spawned
> >> > +                                simultameously, but one at a time while connections come it
> >> > +                                until n are running. Because of the nature of SO_REUSEPORT workers are
> >> > +                                spawned at an exponentially decreasing rate to the number of incoming connections.</para></listitem>
> >> > +                        </varlistentry>
> >> > +
> >> > +                        <varlistentry>
> >>
> >> Hmm, so I think support for SO_REUSEPORT should just be a special case
> >> of the Distribute= logic. i.e. When Distribute= is set but ReusePort is
> >> off, then we'd pass the same original listening socket to all services
> >> we spawn. If Distribute is set but ReusePort is on then we'd create a
> >> new socket when we want to spawn a new instance, and simply bind it to
> >> the same sockaddr as the original one.
> What types of sockets allow multiple bind()s/accept()s without SO_REUSEPORT?
> I don't see what the use is having a socket passed to children that
> can't be used.
> >>
> >> Thinking about this: I have the suspicion that LazyDistribute shouldn't
> >> be an option but the normal and only behaviour...
> > Agreed.
> OK
> >
> > Also, I think ReusePort=1 should be the default if Distribute is used,
> > and the kernel supports it. I don't think there are any downsides.
> ReusePort=1 makes it where systemd no longer "sits" on the port which
> prevents rogue applications
> (root for <1024) from stealing the port.
"To prevent unwanted processes from hijacking a port that has already
been bound by a server using SO_REUSEPORT, all of the servers that
later bind to that port must have an effective user ID that matches
the effective user ID used to perform the first bind on the socket. "
(https://lwn.net/Articles/542629/).

So systemd still "sits" on the port, and only programs running as root
can open the port. There is a corner case, where before a program running
as root could not open it, but now it can, even though it might not
have full root priviledges. I'd just document this special case.

Zbyszek