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

Leon Busch-George leon at georgemail.de
Mon Aug 10 10:02:25 UTC 2026 

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=-

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

> 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!

> 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