Hi Simon, Thanks for your explanations :). My answers follow, a new service file is attached.
Excerpts from Simon Kelley's message of 2011-09-05 14:39:42 +0200:
> Dnsmasq needs to be started as root, but it needs the command-line
> argument --user=dnsmasq, to tell it to change to user dnsmasq _after
> binding port 53, etc etc.
Yep.
> The reason for this is security: dnsmasq is handling untrusted network
> data and is theoretically vulnerable to compromise by buffer overflow
> etc. If it happens, much better that an attacker has control of a
> process _not_ running as root. "nobody" is used in the source because
> that's a non-root, non-real-person user that's available everywhere and
> will therefore work for source installs. For Debian, we make a user just
> for this, since a user that has no writable files, no shell, no home dir
> and is not used for anything else is more secure again. It would be
> possible to patch the source s/nobody/dnsmasq/ but it's easier to do
> this in the startup script than maintain the patch.
You are partly right, partly wrong. Partly wrong because:
1) nobody has no files at all (find / -uid 65534 brings no results on my
system, also see for example bug #618474 where creation of files owned by
nobody is a serious policy violation)
2) nobody has no homedir (while 'dnsmasq' has one!)
But partly right because:
3) Indeed, nobody has a shell.
4) With "is not used for anything else" I guess you mean that nobody
potentially runs/controls processes.
Therefore, I have added an appropriate comment to the systemd service file and
added the --user dnsmasq option :).
> /var/lib/misc/dnsmasq.leases is the persistent DHCP lease database, it
> has to survive over reboot. It's also opened whilst dnsmasq is still
> root, so isn't owned by user dnsmasq.
Ah, you are right, it’s owned by root, my mistake.
> The only file that's owned by dnsmasq is the directory /var/run/dnsmasq.
> That's done so that the PID file /var/run/dnsmasq/dnsmasq.pid can be
> deleted by dnsmasq as it exits, even though dnsmasq isn't running as
> root then. That location for the PID file isn't the standard one either,
> so gets overridden on the command line.
Well, we don’t need a PID file when using systemd. In sysvinit it’s mainly used
for locking and sending signals. systemd supports $MAINPID in the ExecReload=
command, so we don’t need it for sending signals. Since systemd also knows best
if a service still lives or not, we don’t need it for that purpose either.
If a program *really* needs to get the PID, it can easily do that using:
systemctl show -p MainPID dnsmasq.service
> > I am still not quite sure about why we need it and what the effects really
> > are.
> > Of course, log messages appear in a different language after setting LANG.
> > But what exactly is the behaviour when resolving? Why does the LANG setting
> > of
> > my *server* define which answers my clients get?
>
> It doesn't, it tells dnsmasq what character encoding to expect for
> internationalised domain name strings which appear in configuration
> files on the _server_. By the time they get over the network they've
> been transformed into a network-neutral representation.
I see. I’ve added an appropriate comment and now read /etc/default/locale in
the service file.
> Same service file for all distros is unlikely to be possible, I think,
> given the above.
Yeah :-(. Too bad, but well, maybe it works for other services.
> It can't be set to the current system domain name that way
>
> DOMAIN_SUFFIX=`dnsdomainname`
Hrm, that’s correct. Is that really relevant? For systems where the domain
often changes, dnsmasq is probably started by NetworkManager anyways. On other
systems, it’s not too much effort to put the domain name in /etc/dnsmasq.conf.
If you insist, we have two possibilities:
1) Make dnsmasq capable of getting the DNS domain name on its own. It’s not too
much code, I’ve ripped out the appropriate parts of 'hostname', it’s less
than one page of code, see http://p.nnev.de/2017. Not sure if it becomes
even less code when using functions which are in your code-base already.
Advantages: You could make that lookup asynchronuous, thus starting dnsmasq
faster (it does not have to wait blockingly on resolving the hostname but
can immediately show up on DBus). Also, we don’t have to use shell in the
boot process just for expanding the parameter.
2) Start /bin/sh -c 'dnsmasq …' in the service file.
Advantages: No code changes to dnsmasq.
I do prefer the first option. What do you think?
Best regards,
Michael
dnsmasq.service
Description: Binary data
