[Dnsmasq-discuss] [PATCH] don't setgroup to root
Simon Kelley
simon at thekelleys.org.uk
Sun Aug 9 20:22:28 UTC 2026
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.
So that answer was there all along, just start dnsmasq with --group and
your container problem is solved.
The only patch required is to make this clear in the man page. I've done
that.
https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=8d8ad76d896f8eff3bd59dcdb207062c7466a49f
Cheers,
Simon.
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