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

John Crispin blogic at openwrt.org
Sat Apr 30 05:36:19 EDT 2016



On 30/04/2016 10:10, Daniel Golle wrote:
> Hi!
> 
> 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...
> 
> 
> Cheers
> 
> 
> Daniel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 

i am working on a uci-defaults script for base-files that will sync the
user ids after sysupgrade with those in the opkg cache to mitigate the
OMG HAVOC </panic>
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list