A machine might exist on multiple networks, all of which offer, say, default
routes or name servers. There's no easy way to indicate in the config
that those options are only valid for a single interface.
Now, we can write:
interface "lan0" {
request routers;
require routers;
}
interface "lan1" {
ignore routers;
}
And only take action on default routes offered on lan0.
Tested by: Jose Luis Duran <jlduran at gmail dot com>
MFC after: 2 months
Reviewed by: allanjude, imp
Sponsored by: Zenith Electronics LLC
Sponsored by: Klara, Inc.
Pull Request: #693
Else out-of-bound reads and undefined behaviour may happen.
The current code only checked for the presence of the first of four bytes.
Make sure the fields in question have the minium size required.
No functional change intended.
Reviewed by: rrs@
MFC after: 1 week
Sponsored by: NVIDIA Networking
The previous revision missed the exact same error in a copy paste block
of the same code in another function. Fix the identical case, too.
A DHCP client identifier is simply the hardware type (one byte)
concatenated with the hardware address (some variable number of bytes,
but at most 16). Limit the size of the temporary buffer to match and
the rest of the calculations shake out correctly.
PR: 238022
Reported by: Young <yangx92 AT hotmail.com>
Submitted by: Young <yangx92 AT hotmail.com>
MFC after: I don't plan to but you should feel free
Security: yes
MTU if we've set it once and there were no changes on the DHCP server
side since the last refresh. This is consistent I believe with how dhclient
handles other settings like IP address, mask etc.
Approved by: cem, eugen
Differential Revision: https://reviews.freebsd.org/D18546
r343896 made it such that a non-zero exit status was passed through, but was
still wrong if the script exits on a signal. POSIX does not say what the
WEXITSTATUS macro returns in this case and in practice 0 is a common value.
Instead, translate the wait status into 8 bits the same way as the shell
calculates $?.
Reviewed by: kib, Nash Kaminski
MFC after: 1 week
This is also OpenBSD rev. 1.117, as pointed out by
Ryan Moeller <ryan@ixsystems.com>.
Submitted by: Nash Kaminski <nashkaminski@gmail.com>
MFC after: 1 week
This is needed to be able to chroot in the fallback case where
Capsicum is not available.
Reported by: Daniel Braniss <danny@cs.huji.ac.il>
X-MFC with: r337382
Sponsored by: The FreeBSD Foundation
The main dhclient process is Capsicumized but also chroots to
restrict filesystem access. With r322369, pidfile(3) maintains a
directory descriptor for the pidfile, which can cause the chroot
to fail in certain cases. To minimize the problem, only chroot
if we fail to enter capability mode, and store dhclient pidfiles
in a subdirectory of /var/run, thus restricting access via
pidfile(3)'s directory descriptor.
PR: 223327
Reviewed by: cem, oshogbo
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D16584
A more correct way to modernize code that uses __progname is to just
replace each occurance of it with a call to getprogname(3)
Reported by: ian
Reviewed by: imp
- add static in a number of places
- initialize __progname rather than rely on magical extern values
- use nitems() instead of manually spelling it out
- unshadow 'idi'
- teach 'error' that it is '__dead2'
- add missing 'break'
In some cases broken DHCP servers might send invalid MTU value, so allow to
use 'supersede' in dhclient.conf to override this. When superseded value is
0, MTU value is not updated at all.
PR: 206721
Submitted by: novel@
Reported by: <jimp AT pfsense.org>
MFC after: 37 minutes (if you care about 11, please MFC to 11.2)
Relnotes: yes (potentially surprising behavior change w/ broken dhcpd mtu)
Differential Revision: https://reviews.freebsd.org/D15484
When dhclient first starts, if an old IP address exists in the
dhclient.leases file, dhclient(8) sends early DHCPREQUEST message(s)
in an attempt to re-obtain the old IP address again. These messages
contain the old IP as a requested-IP-address option in the message
body (correct) but also use the old IP address as the packet's source
IP (incorrect).
RFC2131 sec 4.1 states:
DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0.
The use of the old IP as the packet's source address is incorrect if
(a) the computer is now on a different network or (b) it is on the
same network, but the old IP has been reallocated to another host.
Fix dhclient to use 0.0.0.0 as the source IP in this circumstance
without removing any existing functionality. Any previously-used old
IP is still requested in the body of an early DHCPREQUEST message.
PR: 199378
Submitted by: J.R. Oldroyd <fbsd@opal.com>
Reported by: J.R. Oldroyd <fbsd@opal.com>
Reviewed by: cem, asomers, vangyzen
MFC after: 1 week
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D14527
Mostly const-correctness fixes. There were also some variable-shadowing,
unused variable, and a couple of sockaddr type-correctness changes. I also had
trouble with cast-align warnings. I was able to prove that one of them was a
false positive. But ultimately I had to disable the warning program-wide to
deal with the others.
Reviewed by: cem
MFC after: 3 weeks
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D14460
Mainly focus on files that use BSD 3-Clause license.
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
dhclient(8) is chrooted so opening /dev/null always will fail.
In capability world this is also annoying because we getting error that
open(2) is not permitted in Capsicum. dhclient(8) is closing stdio by
precaching fd to /dev/null before chroot.
This is done few lines below daemon(3) function so let's not try to do that
in daemon(3) function.
Reviewed by: cem@
Differential Revision: https://reviews.freebsd.org/D12826
dhclient(8) is failing during boot to connect to the syslog service, because
syslog daemon is started after dhclient(8). This can be reproduced by stooping
syslog daemon and ktrace the dhclient or use kern.trap_enotcap sysctl and boot
the machine. Using the Casper syslog service fix the problem.
Reviewed by: bapt@
Differential Revision: https://reviews.freebsd.org/D12825
They would overflow a signed 32-bit time_t on 32 bit architectures. This
was taken care of, but a compiler optimisation makes this behave
erratically. This could be resolved by adding a -fwrapv flag, but
instead we can check the value before adding the current timestamp to
it.
In the lease file values are still wrong though:
option dhcp-rebinding-time -644245096;
PR: 218980
Reported by: Bob Eager
MFC after: 2 weeks
Also make sure that the renewal is never more than 1/2 * expiry and
rebind never more than 7/4 * renewal (the default values in the spec).
This should allow adjusting high values from the server as well as
making sure the values from the server make sense.
Renewal and rebind times will be adjusted down if the expiry time is set
very high in a server, not the other way around. This change just makes
sure the values keep making sense.
Make dhclient set interface MTU if it was provided.
This version implements MTU setting in dhclient itself before it runs
dhclient-script.
PR: 206721
Submitted by: novel@
Reported by: Jarrod Petz <jlpetz at gmail.com>
Reviewed by: cem, allanjude
Differential Revision: https://reviews.freebsd.org/D5675
A DHCP client identifier is simply the hardware type (one byte) concatenated
with the hardware address (some variable number of bytes, but at most 16).
Limit the size of the temporary buffer to match and the rest of the
calculations shake out correctly.
This is a follow-up to the incorrect r299512, reverted in r300172.
CIDs: 1008682, 1305550
Sponsored by: EMC / Isilon Storage Division
It broke client identifiers because I misunderstood the intent of the code.
There is still a minor issue detected by Coverity (at least, I can't find where
the code proves it isn't an issue). I'll follow up with a better fix for the
CIDs.
Reported by: Ian FREISLICH
Sponsored by: EMC / Isilon Storage Division
There was some confusion about how to limit a hardware address to at most 16
bytes. In some cases it would overrun a byte off the end of the array.
Correct the types and rectify the overrun.
Reported by: Coverity
CIDs: 1008682, 1305550
Sponsored by: EMC / Isilon Storage Division
In Azure, the DHCP servers add private option (id 0xf5), which contains
binary form of an IPv4 address. Once this option is converted to string
form, it could contain '$', e.g.
IPv4 address: 100.72.36.54
binary form: 0x64 0x48 0x24 0x36
string form: "dH$6"
dhclient bails upon "illegal" options like the above example, thus the
VM bring-up will fail.
Also as a side note, this "illegal" option detection was added in
OpenBSD ~11years ago:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/dhclient.c?rev=1.50&content-type=text/x-cvsweb-markup
And it was removed along with the removal of script support in OpenBSD
~3years ago:
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/dhclient.c?rev=1.159&content-type=text/x-cvsweb-markup
Reported by: Hongxiong Xian <v-hoxian microsoft com>
Reviewed by: jhb, Dexuan Cui <decui microsoft com>
Tested by: Hongxiong Xian <v-hoxian microsoft com>
Analyzed by: Dong Liu <doliu microsoft com>
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D5853
CAP_FCNTL_GETFL. Without CAP_FCNTL_GETFL, the lease file truncation
in rewrite_client_leases() will fail to trim old data when rewriting
the file with a lesser amount of data.
Reviewed by: pjd, rwatson
Approved by: jmallett (mentor)
MFC after: 1 week
in the future in a backward compatible (API and ABI) way.
The cap_rights_t represents capability rights. We used to use one bit to
represent one right, but we are running out of spare bits. Currently the new
structure provides place for 114 rights (so 50 more than the previous
cap_rights_t), but it is possible to grow the structure to hold at least 285
rights, although we can make it even larger if 285 rights won't be enough.
The structure definition looks like this:
struct cap_rights {
uint64_t cr_rights[CAP_RIGHTS_VERSION + 2];
};
The initial CAP_RIGHTS_VERSION is 0.
The top two bits in the first element of the cr_rights[] array contain total
number of elements in the array - 2. This means if those two bits are equal to
0, we have 2 array elements.
The top two bits in all remaining array elements should be 0.
The next five bits in all array elements contain array index. Only one bit is
used and bit position in this five-bits range defines array index. This means
there can be at most five array elements in the future.
To define new right the CAPRIGHT() macro must be used. The macro takes two
arguments - an array index and a bit to set, eg.
#define CAP_PDKILL CAPRIGHT(1, 0x0000000000000800ULL)
We still support aliases that combine few rights, but the rights have to belong
to the same array element, eg:
#define CAP_LOOKUP CAPRIGHT(0, 0x0000000000000400ULL)
#define CAP_FCHMOD CAPRIGHT(0, 0x0000000000002000ULL)
#define CAP_FCHMODAT (CAP_FCHMOD | CAP_LOOKUP)
There is new API to manage the new cap_rights_t structure:
cap_rights_t *cap_rights_init(cap_rights_t *rights, ...);
void cap_rights_set(cap_rights_t *rights, ...);
void cap_rights_clear(cap_rights_t *rights, ...);
bool cap_rights_is_set(const cap_rights_t *rights, ...);
bool cap_rights_is_valid(const cap_rights_t *rights);
void cap_rights_merge(cap_rights_t *dst, const cap_rights_t *src);
void cap_rights_remove(cap_rights_t *dst, const cap_rights_t *src);
bool cap_rights_contains(const cap_rights_t *big, const cap_rights_t *little);
Capability rights to the cap_rights_init(), cap_rights_set(),
cap_rights_clear() and cap_rights_is_set() functions are provided by
separating them with commas, eg:
cap_rights_t rights;
cap_rights_init(&rights, CAP_READ, CAP_WRITE, CAP_FSTAT);
There is no need to terminate the list of rights, as those functions are
actually macros that take care of the termination, eg:
#define cap_rights_set(rights, ...) \
__cap_rights_set((rights), __VA_ARGS__, 0ULL)
void __cap_rights_set(cap_rights_t *rights, ...);
Thanks to using one bit as an array index we can assert in those functions that
there are no two rights belonging to different array elements provided
together. For example this is illegal and will be detected, because CAP_LOOKUP
belongs to element 0 and CAP_PDKILL to element 1:
cap_rights_init(&rights, CAP_LOOKUP | CAP_PDKILL);
Providing several rights that belongs to the same array's element this way is
correct, but is not advised. It should only be used for aliases definition.
This commit also breaks compatibility with some existing Capsicum system calls,
but I see no other way to do that. This should be fine as Capsicum is still
experimental and this change is not going to 9.x.
Sponsored by: The FreeBSD Foundation
that looks for interface skips interfaces that are not UP. We need to call
dhclient-script PREINIT before we call discover_interfaces(), so the script has
a chance to bring the interface UP.
Reported by: alfred
Revoke all capability rights from STDIN and allow only for write to STDOUT and
STDERR. All those descriptors are redirected to /dev/null.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Once PID is written to the pidfile, revoke all capability rights.
We just want to keep the pidfile open.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Limit routing socket so only poll(2) and read(2) are allowed (CAP_POLL_EVENT
and CAP_READ). This prevents unprivileged process from adding, removing or
modifying system routes.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Currently it was allowed to send any UDP packets from unprivileged process and
possibly any packets because /dev/bpf was open for writing.
Move sending packets to privileged process. Unprivileged process has no longer
access to not connected UDP socket and has only access to /dev/bpf in read-only
mode.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
The gethostname(3) function won't work in capability mode, because reading
kern.hostname sysctl is not permitted there. Cache hostname early and use
cached value later.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
