process management of the contraint processes has been moved from ntp
to the parent, for better privsep and pledge, but the ntp process
still attempted to kill the constraints on timeout directly. Fix this
regression by introducing a new imsg from ntp to the parent and the
related logic to kill a constraint at the right place.
Reported & tested by bcook@
Ok bcook@
actually remove this header. It was originally added for ports, which is
malloc.h-free now.
additional ports bulk by aja@
ok bently@ dcoppa@ millert@ sthen@
The 'A' option elevated warnings to errors, and has been the default for some
time. Then warnings were effectively eliminated in favor of everything
being an error, but then the 'a' flag turned real errors into warnings!
Remove the 'a' option entirely. You shouldn't have used it anyway.
ok tb tdeval
Work around this particular case by reseeding whenever pid=1, but as guenther@
notes, directly calling clone(2), and then forking to match another pid,
provides other ways to bypass new process detection on Linux.
Hopefully at some point Linux implements something like MAP_INHERIT_ZERO, and
does not invent a corresponding mechanism to subvert it.
Noted by Sebastian Krahmer and the opmsg team.
See http://stealth.openwall.net/crypto/randup.c for a test program.
ok beck@
if the data is needed. Use O_CLOEXEC on the internal fd as MT paranoia.
Fix cast in offset calculation; delete register keyword;
prefer memset() over bzero()
ok millert@
This patch adds a new driver for use of virtio-console devices as
ttys. It's still in an early state and not compiled by default, yet.
Currently it is only wired into amd64. i386 is still missing.
Discussed with uebayasi@, deraadt@
the daemon is actually running (instead of only when using rc_bg).
This *may* trigger the following side effect: if a daemon starts then stops
right away (because of a config parsing issue for e.g.), then it will slow down
the boot process because rc will wait a bit before considering the start action
failed. But at least it will allow us to detect those daemons and fix them or
their rc.d(8) script.
At least as far as I can tell, all base daemons should cope with it just fine.
ok sthen@ robert@ on an earlier diff
tell you that the daemon succesfully started; prevent this by running a config
check first.
Note that we only do this for those particular daemons, not all that support a
config test mode.
ok benno@ phessler@