syslog-read 1 user commands nosh
syslog-read RFC 5426 server
`syslog-read`

## Description

`syslog-read` is an RFC 5426 server that feeds a log-writing service of some sort. It loops forever, reading syslog datagrams and writing them to its standard output.

It expects file descriptor 3 to be a socket that has been set up, with udp-socket-listen 1, local-datagram-socket-listen 1, or similar, to listen for incoming datagrams.

No attempt is made to rectify, or even modify at all, messages that do not conform to RFC 5424; and messages that are conformant to only RFC 3164 will be successfully handled. In practice this is still the overwhelming majority of messages. For examples: Messages generated by GNU libc and by the systemd journal dæmon are not in RFC 5424 form.

Before each message, it prints the IP address and port number from which the datagram has been received, if the socket is a network socket. Usually, its standard error will be redirected to an instance of cyclog 1 or similar. This will (presuming an RFC-compliant formatted message) place two timestamps on each log message, the timestamp added by the sender and the timestamp when the message was sent to the log file by the log service. This can be useful for remote logging services, in the face of network latency or desynchronized clocks.

This server does expect a datagram socket and senders speaking the RFC protocols, however. It is not suitable for use with operating system kernel log transports such as `/dev/klog`, `/dev/kmsg`, and `/proc/kmsg`, which have a non-RFC 5424 message format and which are not datagram-based. For those, see klog-read 1.

## Security

Unlike other syslog servers, this server has no need to be run as the superuser. It writes to no files or directories, requires no ownership of any files or directories, and does not even need privileged permissions for socket access since it expects to inherit its socket already opened and bound from the process that chain-loaded it.

This server does not interpret or execute message content received from clients, and does no message categorization or other such processing based upon potentially attacker-supplied information. Its read buffer is a fixed size, with no size calculations at all, let alone ones based upon potentially attacker-supplied length fields. The operating system's recvfrom 2 library function is expected to truncate overlong messages, per POSIX.

Message content is as secure as the underlying transport. The protocol itself provides no defences against forgery, no defences against flooding, no defences against malformed character encodings or control characters, nor authentication mechanisms for clients.

It is recommended that one run entirely separate RFC 5426 services, running under the aegises of different user accounts and attached to separate logging services and separate destination logfiles, for network-accessible sockets and locally-accessible sockets (i.e. for UDP and for the conventional AF_LOCAL `/run/log` socket). This at least militates against any attacks that flood or compromise the network-accessible service (and logfiles) also affecting locally-accessible logging; even though locally-accessible syslog logging remains wide open to an attacker who has local, unprivileged, access.

It is also strongly recommended that whatever log-writing service it feeds run under a different user account. That log-writing service must be able to handle malformed character encodings and the presence of control characters (including NUL).

## Author

Jonathan de Boyne Pollard