syslogd: Ensure that forwarded messages are sent from port 514

Prior to commit 4ecbee2760f7, syslogd used its listening socket(s) to
forward messages to remote hosts, when so configured. As a conse

syslogd: Ensure that forwarded messages are sent from port 514

Prior to commit 4ecbee2760f7, syslogd used its listening socket(s) to
forward messages to remote hosts, when so configured. As a consequence,
they are sent from the address+port to which those sockets are bound,
typically 0.0.0.0:514.

When in capability mode, sendto() is not permitted, so we instead
pre-create sockets and connect them to the forwarding addresses, letting
the kernel pick an ephemeral source port. However, this doesn't match
syslogd's previous behaviour, breaking some setups.

So, restore the old behaviour by binding forwarding sockets to the
addresses on which syslogd is listening. Since we cannot use the same
sockets for receiving messages and also for forwarding them, use
SO_REUSEPORT to enable duplicate bindings to port 514, relying on the
existing behaviour that the first socket bound to that port is the one
that actually receives messages.

Add some regression tests to cover this and related functionality of
syslogd's -a option.

Reviewed by: jfree
Reported by: Michael Butler <imb@protected-networks.net>
Fixes: 4ecbee2760f7 ("syslogd: Open forwarding socket descriptors")
Differential Revision: https://reviews.freebsd.org/D48222

show more ...

syslogd: Open forwarding socket descriptors

Previously, when forwarding a message to a remote address, the target's
addrinfo was saved at config-parse-time. When message-deliver-time came,
the messa

syslogd: Open forwarding socket descriptors

Previously, when forwarding a message to a remote address, the target's
addrinfo was saved at config-parse-time. When message-deliver-time came,
the message's addrinfo was passed into sendmsg(2) and delivered by the
first available inet socket.

Passing an addrinfo into sendmsg(2) is prohibited in Capsicum capability
mode, so sockets are now opened and connected to their remote peers at
config-parse-time when executing outside of the capability sandbox.

These connected socket descriptors are saved and passed into sendmsg(2),
allowing forwarding to be performed inside of the capability sandbox.

Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D47104

show more ...

syslogd: Log messages using libcasper

Some logging operations require access to external resources to
complete. Logging to F_WALL requires on-demand access to the user
accounting database. Logging t

syslogd: Log messages using libcasper

Some logging operations require access to external resources to
complete. Logging to F_WALL requires on-demand access to the user
accounting database. Logging to F_CONSOLE requires access to the
console. Logging to F_PIPE prompts execution of a command outside
of capability mode.

These operations cannot be performed in capability mode, so the
"p_open", "ttymsg", and "wallmsg" commands may be sent to libcasper to
circumvent these limitations.

Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D41465

show more ...

syslogd: Refresh configuration using libcasper

When a SIGHUP signal is sent to syslogd, the configuration is reparsed,
leading to new resource acquisition.

If syslogd is running in capability mode

syslogd: Refresh configuration using libcasper

When a SIGHUP signal is sent to syslogd, the configuration is reparsed,
leading to new resource acquisition.

If syslogd is running in capability mode and a SIGHUP is received, new
resources cannot be acquired. To mitigate this issue, libcasper is used
to parse the configuration.

The libcasper process runs outside of capability mode and is capable of
parsing syslogd's configuration and obtaining new resources. These
resources are then sent to the syslogd process via nvlist.

Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D41464

show more ...