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

[Simon Kelley]

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?

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.

I think I slightly prefer extending --group to adding --nogroup, but if 
you write the patch, you can make the final choice.


Cheers,

Simon.




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))
>>>    	{
>>
> 
>