On Thu, Jun 21, 2018 at 09:42:17AM -0400, Greg Troxel wrote: > > Paul Goyette <p...@whooppee.com> writes: > > > On Thu, 21 Jun 2018, Kamil Rytarowski wrote: > > > >> Module Name: src > >> Committed By: kamil > >> Date: Thu Jun 21 11:02:48 UTC 2018 > >> > >> Modified Files: > >> src/external/mpl/dhcp: Makefile.inc > >> > >> Log Message: > >> Make building of dhcp compatible with MKSANITIZER > >> > >> Disable LD flags (-Wl,-Bstatic and -Wl,-Bdynamic) with enabled MKSANITIZER. > >> These options are incompatible with the current design of sanitizers, > >> because they cause duplication of symbols into programs and thus symbols > >> from the interceptors from sanitizers cannot be linked. > >> > >> This change makes effectively mounting /usr required for dhcp programs like > >> dhclient(8). > > > > This could be difficult if /usr is nfs-mount and requires dhcp and > > friends for setting up the network. > > I'm not following this but something seems strange. > > Are you really saying that a program that is in /sbin will not work with > /usr not mounted? That seems quite broken; the whole point of /sbin > being separate from /usr/sbin was always that things would work without > /usr. > > So it seems more reasonable to conclude that dhclient must be excluded > from the sanitizer than that it should fail without /usr. > > (There's the whole issue of whether ISC dhclient is so big that it > doesn't belong in sbin, switching to dhcpcd, etc., but those are > separate issues.)
It's for sanitizers, you shouldn't normally run a sanitizer userland, it is for development purposes. Ignoring /usr being possibly unmounted is sensible, the alternative is otherwise to not audit dhclient, but it's the sort of program we really want to fuzz/sanitize... (accepts network input, runs with extra privileges, etc.)
