[OpenWrt-Devel] r49252 (dnsmasq: run as dedicated UID/GID) causing major havoc

Daniel Golle daniel at makrotopia.org
Sat Apr 30 04:10:19 EDT 2016


On Sat, Apr 30, 2016 at 10:20:05AM +0300, Hannu Nyman wrote:
> r49252 (dnsmasq: run as dedicated UID/GID) seems to be causing major havoc.
> So far at least 5 bugs about it: #22271, #22277, #22278, #22300, #22303
> The change to require a separate userid & group for dnsmasq without
> providing any transitioning mechanism effectively prevents dnsmasq from
> starting if the userid is not there. In practice this kills DNS & DHCP for
> anybody who:
> a) applies DD trunk sysupgrade with preserving old settings,
> b) restores a previous settings backup,
> c) upgrades later from AA/BB/CC to the forthcoming DD release while
> preserving settings
> So, this headache will not go away easily. I think that we need a
> transitioning mechanism to ensure that dnsmasq starts despite the possibly
> missing userid.

> I see three alternatives:
> 1) dnsmasq startup init script checks for dnsmasq user's presence and if
> yes, only then apply the separate userid parameter for dnsmasq
> 2) dnsmasq startup init script checks for dnsmasq user's presence and
> creates the user if not present
> 3) uci-defaults script added to dnsmasq package to create the new user at
> the first boot (note that this solution might not solve the case b for
> restoring an earlier settings backup later )

Adding a uci-defaults script for the dnsmasq package in charge of
migrating the old/existing configuration would be the appropriate
thing to do. Restoring an outdated config at a later point will
always break a lot of things and thus I wouldn't explicitely
work-around that case, it's just something folks shouldn't do or be
aware that manual cleaning will be needed when restoring a config
which doesn't belong to what's actually installed.

> I am not sure what might be optimal in the long run. 2) creating the user
> might provice most uniform behaviour later

I don't like bloating init scripts unless there really isn't any other
way to solve a problem...


openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list