[Dnsmasq-discuss] [PATCH] don't setgroup to root

Simon Kelley simon at thekelleys.org.uk
Thu Aug 13 11:54:26 UTC 2026 


On 10.08.2026 11:02, Leon Busch-George wrote:
> Hello Simon :-)
> 
> On Sun, 9 Aug 2026 21:22:28 +0100
> Simon Kelley <simon at thekelleys.org.uk> wrote:
> 
>> I chased the existing code a little further on this.
>>
>> The behaviour is this.
>>
>> If started as non-root, nothing  is done.
>>
>> If --user is not given, change user to "nobody"
>>
>> If --group is not given, change group to "dip" if it exists,
>> otherwise change group to the main group associated with the user
>> above.
>>
>> If --group is given _with_a_value, change group the specified group.
>>
>> If --group is given, but without a value, don't change group at all.
> 
> That's the first thing I tried after a look at the code but I just couldn't
> get it to work:
> 
>      $ dnsmasq -u root -g --log-facility=- ..
>      dnsmasq: unknown user or group: --log-facility=-

That's strange....   <does experiments>

Everyday is a school day. It seems that gnu-getopt only supports 
optional arguments for _long_ options

  $ dnsmasq -u root -group --log-facility=-

works fine, and --group is what I used in my testing so I never noticed.

> 
> I seem to remember also trying a line saying only "group" in the config
> file.


I checked, and that works for me OK.>
>> So that answer was there all along, just start dnsmasq with --group
>> and your container problem is solved.
> 
> Let me try it again when I get back home later.
> 
>> The only patch required is to make this clear in the man page. I've
>> done that.
> 
> Well, thanks for the clarification! If that is how it's supposed to work and
> it somehow doesn't, I'll report back.
> Otherwise, I'm sorry for stirring you up!

No problem. We all learned something!


Simon.>
>> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=8d8ad76d896f8eff3bd59dcdb207062c7466a49f
>>
>> Cheers,
>>
>> Simon.
> 
> kind regards,
> Leon
> 
>> On 06.08.2026 11:23, Leon Busch-George wrote:
>>> Hello Simon :-)
>>>
>>> Please excuse my clumsiness with the duplicate email - again.
>>>
>>> On Tue, 28 Jul 2026 16:02:21 +0100
>>> Simon Kelley <simon at thekelleys.org.uk> wrote:
>>>
>>>> Just to be clear, the current patch works because you're
>>>> configuring "group=root" and inhibiting setgid(0). I see how that
>>>> works, since then end-state is only achievable if the start state
>>>> is gid==0, so existing configurations are not affected. Have I got
>>>> that right?
>>>
>>> Right. I can't think of a case where setting 0 -> 0 is important.
>>> Groups are a little special because groups can be used to restrict
>>> permissions and setgid is disallowed by default (setgroups) in
>>> unshared namespaces to prevent groups from being dropped (possibly
>>> expanding privileges), iirc.
>>>
>>>> I think --nogroup or --group without an argument are cleaner too.
>>>> If for no other reason than it's much easier to describe what the
>>>> semantics are. (To inhibit setgid() set group to "root" and start
>>>> as group root, vs To inhibit setgiud use --nogroup or --group with
>>>> no argument.
>>>
>>> My honest take is that "nogroup" is clearer. A patch should be on
>>> the mailing list. I went for the "grp_id != 0" primarily to mimic
>>> the existing check for the uid. I've added a "nouser" option for
>>> consistency. If you're interested, maybe I can cook up a deprecation
>>> warning for "ent_pw->pw_uid != 0".
>>>
>>>> I think I slightly prefer extending --group to adding --nogroup,
>>>> but if you write the patch, you can make the final choice.
>>>
>>> I don't feel adequately equipped to decide this.
>>>
>>> There are advantages to both alternatives. The core difference, in
>>> my eyes, is "be clear and robust" on one hand and "keyhole surgery"
>>> on the other. Both patches are on the list now and both are
>>> appropriate.
>>>
>>> If you have trouble deciding, I think you should go with your
>>> instinct and discard my new patch - no offence will be taken.
>>>
>>>> Cheers,
>>>>
>>>> Simon.
>>>
>>> kind regards,
>>> Leon
>>>
>>>>
>>>> On 28.07.2026 14:43, Leon Busch-George wrote:
>>>>> Hi :-)
>>>>>
>>>>> I agree about not breaking existing configurations. The only way I
>>>>> can see the patch could break existing setups is when somebody is
>>>>> switching from a non-root GID to root. In theory, a cleaner
>>>>> solution would be to compare the existing GID and the target GID.
>>>>>
>>>>> I chose to do the analogue of the check for switching the UID
>>>>> ("pw_uid != 0" on line 692), going off the assumption "We're still
>>>>> running as root here" noted in a comment on line 686 (and the man
>>>>> page).
>>>>>
>>>>> My use case is running dnsmasq in a user namespace ("unshare -Ur")
>>>>> like, for instance, with pasta (also creating a network
>>>>> namespace). In a "bare" user namespace (unshare -U), no
>>>>> users/groups are mapped. There just isn't anything to switch to -
>>>>> even if setgroups was allowed.
>>>>>
>>>>> In these environments, dnsmasq can't be used at all because of
>>>>> setgid. The error is "failed to change group-id"
>>>>> (EVENT_GROUP_ERR). There's no available GID to switch to and the
>>>>> default policy disallows switching. For the UID, there is the
>>>>> 'user=root` workaround (avoid the switch entirely).
>>>>>
>>>>> A "nogroup" option would be clearer and safer for existing
>>>>> configurations (if the "switching to root" scenario is of any
>>>>> concern), albeit inconsistent with the handling of UIDs.
>>>>>
>>>>> Make a wish! I should be able to create a patch for that "nogroup"
>>>>> option.
>>>>>
>>>>> kind regards,
>>>>> Leon
>>>>>
>>>>> On Mon, 27 Jul 2026 21:38:33 +0100
>>>>> Simon Kelley <simon at thekelleys.org.uk> wrote:
>>>>>
>>>>>> Not sure this is the correct solution.
>>>>>>
>>>>>> How are you configuring dnsmasq? If there's no --group option,
>>>>>> then it will try and set the group of the daemon process to
>>>>>> "dip", which is archaic, but quite likely still useful
>>>>>> somewhere, so I don't want to change it.
>>>>>>
>>>>>> Are you overriding the change to "dip" by setting --group=root
>>>>>> and that what's causing the error? Again, there may be
>>>>>> installations where that's in use and required, which I don't
>>>>>> want to break.
>>>>>>
>>>>>> Could the solution to this be --group (with no arg) or a new
>>>>>> --nogroup option which explicitly disables the setgid() call?
>>>>>>
>>>>>>
>>>>>> Simon.
>>>>>>
>>>>>>
>>>>>> On 27.07.2026 13:51, Leon M. Busch-George wrote:
>>>>>>> From: "Leon M. Busch-George" <leon at georgemail.eu>
>>>>>>>
>>>>>>> Without this patch, dnsmasq wont start in namespaces without
>>>>>>> group ID mappings unless setgroups is explicitly allowed (e.g.
>>>>>>> write "allow" to /proc/self/setgroups).
>>>>>>> This happens even if the target gid matches the current one.
>>>>>>>
>>>>>>> Work around this issue by not calling setgroups when the target
>>>>>>> gid is 0, which matches the guard around calling setuid
>>>>>>> (ent_pw->pw_uid != 0). ---
>>>>>>>      src/dnsmasq.c | 2 +-
>>>>>>>      1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/src/dnsmasq.c b/src/dnsmasq.c
>>>>>>> index 8fcbbda..2a3ff33 100644
>>>>>>> --- a/src/dnsmasq.c
>>>>>>> +++ b/src/dnsmasq.c
>>>>>>> @@ -742,7 +742,7 @@ int main (int argc, char **argv)
>>>>>>>            gid_t dummy;
>>>>>>>            
>>>>>>>            /* remove all supplementary groups */
>>>>>>> -      if (gp &&
>>>>>>> +      if (gp && gp->gr_gid != 0 &&
>>>>>>>      	  (setgroups(0, &dummy) == -1 ||
>>>>>>>      	   setgid(gp->gr_gid) == -1))
>>>>>>>      	{
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dnsmasq-discuss mailing list
>>>> Dnsmasq-discuss at lists.thekelleys.org.uk
>>>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>>
>>>
>>
> 
>

More information about the Dnsmasq-discuss mailing list