request:
instead of the -S flag, fix the -s flag to not open a socket
if there are no forwarding rules in /etc/syslog.conf
The behavior of syslogd when -s is specified and there are forwarding rules
should still be made cleaner.
- for sizeof(void *) == 8 arch, this is mandatory. MHLEN is too small
already (less than 80) and there are chances for unwanted packet loss due
to m_pullup restriction.
- for other cases, the change should avoid allocating clusters in most cases
(even when you have IPv4 IPsec tunnel, or IPv6 with moderate amount of
extension header)
portmasters: if your arch chokes with the change (high memory usage or
whatever), please backout the change for your arch.
that gifconfig(8) would issue to configure tunnel endpoints. This
allows IP tunnel interfaces (`gif' right now, and `gre' later) to
be configured with ifconfig(8), and via /etc/ifconfig.<interface>.
Partially taken from similar changes in OpenBSD.
- Const poison the command functions a bit. We really need to clean
up the command function interface.
in man page and comments -- for some time it has no longer prevents
an inet socket from being opened, just caused it to be ignored
2.) Fix this problem with `-s' -- syslogd always opens an inet socket, even if
-s is specified and it has nowhere to send to. This socket is then
shutdown(), but there is no way to not have this socket open.
Users setting up paranoid installations can now specify `-S' which
prevents any non-unix-domain sockets from being opened, even if
forwarding is specified in /etc/syslogd.conf.
As per the previous fix, this is not made the default for `-s', as it
also prevents syslogd from forwarding log messages.
3.) document the above in the man page and usage.
Justification: in light of the possibility of future DoS attacks, or the
desire to set up a machine which is relatively uninformative in the face
of port scans, users may quite legitimately want to control what sockets
are open on their machine. Telling such users that they cannot run
syslogd is non-ideal.
memory that is explicitly mapped in a DMA-coherent manner, we must
make sure to PREREAD sync the RFA after noticing a clear "complete"
bit. Without this, the clear bit will linger in the cache, and the
CPU will not notice when the chip updates the bit via DMA later.
From Izumi Tsutsui on port-arm32@netbsd.org.
wiz