Michael Stapelberg wrote: > So, I reflected about this, and we cannot use User=dnsmasq in the service file > because dnsmasq needs to bind to port 53 as root.
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. 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. > > But aside from that, I wonder why we (as in: Debian) need to use the dnsmasq > user while the default is the 'nobody' user, which we also have in Debian. The > only difference I can spot so far is that the dnsmasq user has /var/lib/misc > as > homedir and dnsmasq stores a file called dnsmasq.leases there. I’m not sure > what the intentions are, but my first question is: why is that file not in > /var/run (and therefore on tmpfs)? /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. 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. The options which are needed on the command line for debian are therefore -x /var/run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new (the last one activates the /etc/dnsmasq.d drop-dir for config fragments.) Possibly the solution is something like ExecStart=/usr/sbin/dnsmasq -k -x /var/run/dnsmasq/dnsmasq.pid \ -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new but somehow maintaing the ability to override the config-dir in /etc/default/dnsmasq > >>>> • LANG gets set if it is defined in /etc/default/locale. I’m not sure >>>> what the >>>> effects of that are (I don’t set LANG on my system, I prefer the LC_* >>>> settings). Does it somehow affect the behaviour of dnsmasq when >>>> resolving? >>>> If so, how? >>> It affects the charset used when reading internationalised domain names >>> from configuration files and the translation used for messages. It's needed. >> OK. I think this could be done with EnvironmentFile=-/etc/default/locale. I >> will test it and add it (including a comment on why it is necessary). > 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. > > The problem I see with using LANG is that /etc/default/locale is > Debian-specific and we want to have the same systemd service file for all > distributions (ideally). Same service file for all distros is unlikely to be possible, I think, given the above. > >>> 1) set the domain to the system value > An important setting, but should be done via /etc/dnsmasq.conf when using > systemd. > It can't be set to the current system domain name that way DOMAIN_SUFFIX=`dnsdomainname` >>> 2) use a different configuration file. > I don’t really see a good reason for that right now, but people who want to do > that should just copy /lib/systemd/system/dnsmasq.service to > /etc/systemd/system/dnsmasq.service and change it appropriately. > >>> 3) set a couple of options which are needed by the Debian installation, >>> without requiring the user to have them in the configuration file. >>> These are the dnsmasq user, and the CONFIG_DIR value. > So, this is a Debian-specific option which we really need :-/. I guess we have > no other option than shipping two files with dnsmasq or keeping a > Debian-specific one in the Debian packaging (the latter sounds better). > See above, I'm answering this one point at a time :-) If possible, I'd like to maintain the functionality of /etc/default /dnsmasq for the options documented in there, with the possible expection of the resolvconf one: I guess we still have to fight the resolvconf battles. Cheers, Simon. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
