Since version 9.3.3 and commit a5348dd02c,
build without fork or signals fails on:
dhcpcd.c: In function ‘main’:
dhcpcd.c:2261:3: error: label ‘start_master’ used but not defined
goto start_master;
^~~~
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This is achieved by checking that the interface is wireless,
IFF_UP and IFF_LOWER_UP are present, but IFF_RUNNING is missing.
This gives exactly the same support as modern NetBSD when carrier
loss is detected, but without the address verifications when the
carrier comes back as that needs to be handled in the kernel.
While IP setup is maintained, other configuration data is discarded.
Note that this should be improved in the future.
Thanks to Boris Krasnovskiy <borkra@gmail.com> for helping with this.
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.
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.
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.
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.
