dhcpcd: Don't create launcher process if keeping in foreground

There is little point.

control: create an unpriv socket for non master mode

This allows `dhcpcd -U4 eth0` to work once more.

When adding a route, the interface will always have options.

Add --noconfigure option

With this set dhcpcd will not configure anything on the host.
The expectation is that a 3rd party script will instead.

fix if_getnetworknamespace matching bug. (#19)

Co-authored-by: Ted Feng <Ted.Feng@Aviatnet.com>

Linux: Fix detecting existing IPv4 addresses

This is important for better NetworkManager support.

options: Don't log unknown option errors when printing the pidfile

Release dhcpcd-9.3.2

Fix compile without various defines

Remove debug from prior

privsep: don't leave a BOOTP process hanging around on SIGUSR1

When not in master mode.

log: Allow logopen to be called without logclose

logclose is meant to free resources.
On Linux this means that _log_prog is also free'd and once in the
chroot we cannot work it out again.

As such allow logopen to close what it needs to so that reopening
works.

privsep: Allow logfile reopening in a chroot

Now that only the privileged actioneer does the actual logging
we can safely reopen the file we are logging to.
This also closes and re-opens the syslog connection.

privsep: Send all log messages to the privileged actioneer

If dhcpcd starts and no syslogd implementation is running then
various syscall filters could be triggered when dhcpcd wants to syslog
and it's already in a chroot.

Not all libc openlog implementations support LOG_NDELAY and
openlog does not return an error code and can also mask errno back to 0.
So we have no way of knowing if we have a syslog connection or not.
This means we cannot cache the connection at startup because syslog itself
will try and open if no connection.

As such, all logging is now directed to the dhcpcd privileged actioneer
process which will handle all the syslog and log file writing actions.

The only downside of this approach (other than an extra fd per process)
is that we no longer know which PID raised the message. While we could
put the correct PID in the logfile as we control the API, we cannot
put it into syslog as we cannot control that API.
As all privsep errors should log which function they came from this
will hopefully not be an issue as on the happy path only the master
process will log stuff.

DHCP: Implement IPv6-Only Preferred option, RFC 8925.

Enable it like so in dhcpcd.conf:
option ipv6_only_preferred

privsep: Close BPF socket on ENXIO.

This stops log spam if RTM_IFANNOUNCE is delayed for the departing
interface.

Bump date for prior

dhcpcd.conf(5): mention fallback for the reboot option

Syncs with dhcpcd(8)

BSD: LINK_UNKNOWN is traditionally treated as LINK_UP

privsep: Allow more syscalls through SECCOMP and add a debugger

This fixes PowerPC at least.

The debugger should not be enabled by default as the attacker
could keep the processes running.
However, it is need to work out which syscall is failing due to the
way SECCOMP works.

Make a note about solaris privileges

duid: plug a potential memory leak

Release dhcpcd-9.3.1

privsep: Minor correction to prior logic

privsep: We need to ensure stderr is valid before testing if tty

privsep: Fix stderr redirection again

privsep: allow gettimeofday for SECCOMP

We need it for logging.

BSD doesn't use envp

setproctitle compat requires envp, not environ

The two could be different!
envp is NOT C or POSIX standard, but does appear to be a UNIX standard.

Just give up with setproctitle on Illumos

Their ps tools go out of their way to only show how it was launched :/

Change copyright on setproctitle.h

compat: Use libbsd's setproctitle(3)

Linux PRCTL variant, although more light weight, doesn't work on
some kernels.
This weighs in around 1k more, but always works.
It does play around with environ and args but unlike other
similar variants doesn't appear to stamp on what you actually
use in the program.

privsep: Always try and open syslog

Even if we don't print as otherwise we can't in a chroot.

privsep: Ensure command is for BPF first and interface valid second

Otherwise we won't call inet_dispatch on a message meant for it.

Linux: fix compile

privsep: Improve rights on launcher fork and stderr fds

privsep: Only start network proxy if we need to

Do this before starting it rather than it shutting down.

privsep: Only log chrooting from the launcher process

And the sandbox tech as well.
Rework stop_interface so we can reuse an option for marking
a process as the launcher.

if: always log about unsupported interface types in debug

dhcpcd: Simplify the link handling even more

Move the IS_LINK_UP macro to if_is_link_up function to reduce
binary size.
Rather than DHCPCD_LINK option controlling the carrier state,
use it in if_is_link_up to determine the outcome.

Wireless must be down if unknown.

dhcpcd: Simplify carrier handling more by using IS_LINK_UP macro

Removes the need for the LINK_DOWN_IFFUP state.
While here, remove the check for IFF_RUNNING when LINK_UNKNOWN
because that is OS specific.

Release dhcpcd-9.3.0

privsep: Remove capsicum specific hooks from BPF

We no longer change the filter as it's locked if the OS supports.

Don't log backticks.

privsep: We need getsockopt as well as setsockopt on the link socket

So we can report receive buffer size.
Important for route(4) overflow so we can try and set a bigger buffer.

privsep: allow CAP_SETSOCKOPT for route(4) fd.

If FreeBSD ever implements RO_MISSFILTER it will need special
rights to work over Capsium.

privsep: We now need to carry ifa_data for BSD

BSD: Fix compile for non NetBSD

Add a comment to prior incase I do something dumb like removing it

in the future if I forgot why it was there.

Fix a typo in a comment

privsep: fix crash when interface departs before bpf returns for it

BSD: struct if_data->ifi_link_state is the single source of truth

Vastly improve and simplify link detection on BSD.
dhcpcd either examines the whole system via getifaddrs(3) or
reacts to events via route(4).
In both cases we have struct if_data which has ifi_link_state.

Armed with this knowledge, we no longer need SIOCGIFDATA or
SIOCGIFMEDIA.

To solve the issue of newly attached interfaces having
LINK_STATE_UNKNOWN or some interfaces not even changing it,
we only change the local knowledge of interface flags when
reports them by getifaddrs(3) or route(4) when we change them.
For example, if we set IFF_UP and it succeeds we don't set this
internally until reported by the kernel as above.

This keeps flags and link state in sync with each other.
The hope is that the kernel can set the real link state before
it reports IFF_UP.

As such, we no longer require the poll option or need to enter a
tight loop for old interfaces.

BSD: Ignore vether(4) devices by default.

Clean up some warnings.

FreeBSD: Anticipate SIOCGIFDATA not working in Capsicum

BSD: NetBSD is the odd man out with SIOCGIFDATA

So setup the #defines like so.
On OpenBSD, pledge blocks it and there is no escape.
Luckily we already allow indirect ioctls via privsep so it works fine.

if: Always warn about ignored interfaces.

BSD: Of course DragonFly does SIOCGIFDATA differently..

Add a warning about prior

Revert double variable define

FreeBSD lacks SIOCGIFDATA it seems.

BSD: Use SIOCGIFDATA if no media support and no ifa_data

Hopefully this nails link state once and for all on BSD.

BSD: Detect initial link state in ifa_data

Not all interfaces report media state to get the link state.
However, link state is available from getifaddrs(3) ifa_data
for AF_LINK addresses.

Testing shows that link state is also sent correctly via
route(4) messages for the same interface.

This makes pppoe(4) interfaces more reliable on FreeBSD and OpenBSD.

dhcpcd: log carrier lost once more

Try and track link state better, regardless of if we're using
the interface or not.

privsep: Don't log sandbox type twice

privsep: Allow __NR_mmap for seccomp

Some malloc implementations might use it rather than brk.

privsep: Don't remove pidfile at exit

The privileged actioneer will remove it.

privsep: Add more platforms for seccomp

Really nutty. Why cannot a system header define a default?

privsep: Allow more syscalls for seccomp

dumplease now works over the control socket and stdin.

privsep: Send signal from launcher to master over the socket

rather than using kill which is not permitted in capsicum.
This also allows us to drop the proc pledge.

privsep: sandbox the launcher process

FreeBSD: Fix build

privsep: Avoid "unconfined" seccomp warnings

Unsure why these are needed atm....

privsep: Don't be noisy about the sandbox

privsep: Log if the platform sandbox is unavailable or available

This is kinda important.

privsep: Add the SECCOMP BPF sandbox for Linux

Now we have capsicum, pledge and the POSIX resource limited sandboxes
this was quite easy really.

Linux: Use SIOCSIFVLAN rather than SIOCSIFVLAN

privsep: Fold capsicum and pledge entry points into ps_entersandbox

Adjust prior so that message is logged before starting dev

Also add os_init incase other os need similar in the future.

Linux: detect network namespace and deny udev in one

udev says whether an interface name is stable or not.
In a network namespace, udev claims the interface does not exist.
This makes sense because udev only operates in the root namespace.

As such disable udev in a network namespace.

While here correctly spell initialise.

duid: Allow optional argument to specify ll or llt alongside uuid

install: Create DBDIR with mode 0750 by default

It shouldn't be 0755 as we might not want everyone to read
DHCP leases.

dhcpcd: Only manipulate stdin, stdout and stderr when valid

UNIX application expect these to exist even if pointed at /dev/null.
We cannot change which fd they use, it's always 0, 1 and 2.
But if these fd's are not open when dhcpcd is called, they could
be assigned to dhcpcd internals.

In this instance we should not use the streams in anyway or form.

logerr: Don't leak the logfile stream to scripts

README: Remove old reference to db dir needing user permissions

We've been using the original dirs since dhcpcd-9.1.

dhcpcd: avoid privsep errors if we error locking the pidfile

Should not happen on the happy path, but if it does, tidy the
resultant errors.

Release dhcpcd-9.2.0

DHCP: Fix compile without IPv4LL

configure: Remove PPOLL from config.mk

privsep: dump leases in a sandbox

dhcpcd: stderr callback fd may the reset by peer

When the process exits which is normal.

privsep: Dump leases from stdin in a limited sandbox

privsep: dropprivs can be static

privsep: limit rights for stdout/stderr/stdin using capsicum

FreeBSD: Don't rights limit stderr

Otherwise some utils in scripts will error with insufficient
capabilities.

dhcpcd: Redirect stdout/stderr to the launcher stderr descriptor

This actually make life really simple!
We no longer need to redirect stdout/stderr to /dev/null for privsep
and any script output is now captured again - and it all goes to stderr
as it should even if a script wants it to go to stdout.

On the happy path, only the master process will actually log anything
to stderr so we turn that off after we "fork".
On the unhappy path, logging to stderr/stdout *may* fail because
the launcher process *may* have exited.
We *could* have the master process as an intermediary but that's
just excess code to avoid errors which *should* not happen.
Regardless, any errror should still hit syslog.

privsep: Fix prior for FreeBSD.

dhcpcd: Setup a socketpair in the launcher to write to stderr

Rather than duping stderr down to the processes.
This allows us to reopen stdout and stderr onto /dev/null right
away and means only the launcher process writes to stderr.

The downside is that any stdout from the script is now lost.
If that's needed, we could setup a stdout socketpair as well.