/mandos/trunk

To get this branch, use:
bzr branch http://bzr.recompile.se/loggerhead/mandos/trunk

« back to all changes in this revision

Viewing changes to plugins.d/splashy.xml

  • Committer: teddy at recompile
  • Date: 2020-04-05 21:30:59 UTC
  • Revision ID: teddy@recompile.se-20200405213059-fb2a61ckqynrmatk
Fix file descriptor leak in mandos-client

When the local network has Mandos servers announcing themselves using
real, globally reachable, IPv6 addresses (i.e. not link-local
addresses), but there is no router on the local network providing IPv6
RA (Router Advertisement) packets, the client cannot reach the server
by normal means, since the client only has a link-local IPv6 address,
and has no usable route to reach the server's global IPv6 address.
(This is not a common situation, and usually only happens when the
router itself reboots and runs a Mandos client, since it cannot then
give RA packets to itself.)  The client code has a solution for
this, which consists of adding a temporary local route to reach the
address of the server during communication, and removing this
temporary route afterwards.

This solution with a temporary route works, but has a file descriptor
leak; it leaks one file descriptor for each addition and for each
removal of a route.  If one server requiring an added route is present
on the network, but no servers gives a password, making the client
retry after the default ten seconds, and we furthermore assume a
default 1024 open files limit, the client runs out of file descriptors
after about 90 minutes, after which time the client process will be
useless and fail to retrieve any passwords, necessitating manual
password entry via the keyboard.

Fix this by eliminating the file descriptor leak in the client.

* plugins.d/mandos-client.c (add_delete_local_route): Do
  close(devnull) also in parent process, also if fork() fails, and on
  any failure in child process.

Show diffs side-by-side

added added

removed removed

Lines of Context:
135
135
        <para>
136
136
          These variables will normally be inherited from
137
137
          <citerefentry><refentrytitle>plugin-runner</refentrytitle>
138
 
          <manvolnum>8mandos</manvolnum></citerefentry>, which will
139
 
          normally have inherited them from
140
 
          <filename>/scripts/local-top/cryptroot</filename> in the
141
 
          initial <acronym>RAM</acronym> disk environment, which will
142
 
          have set them from parsing kernel arguments and
143
 
          <filename>/conf/conf.d/cryptroot</filename> (also in the
144
 
          initial RAM disk environment), which in turn will have been
145
 
          created when the initial RAM disk image was created by
146
 
          <filename
147
 
          >/usr/share/initramfs-tools/hooks/cryptroot</filename>, by
148
 
          extracting the information of the root file system from
149
 
          <filename >/etc/crypttab</filename>.
 
138
          <manvolnum>8mandos</manvolnum></citerefentry>, which might
 
139
          have in turn inherited them from its calling process.
150
140
        </para>
151
141
        <para>
152
142
          This behavior is meant to exactly mirror the behavior of
276
266
    <para>
277
267
      <citerefentry><refentrytitle>intro</refentrytitle>
278
268
      <manvolnum>8mandos</manvolnum></citerefentry>,
279
 
      <citerefentry><refentrytitle>crypttab</refentrytitle>
280
 
      <manvolnum>5</manvolnum></citerefentry>,
281
269
      <citerefentry><refentrytitle>plugin-runner</refentrytitle>
282
270
      <manvolnum>8mandos</manvolnum></citerefentry>,
283
271
      <citerefentry><refentrytitle>proc</refentrytitle>