Description of problem: In F-8, dnsmasq is run under user nobody, group dip. In F-9, this changed to root:dip, however, this change does not seem to be documented in the RPM changelog. Please consider running dnsmasq as non-privileged user, dedicated user is commonly preferred for network-facing services. Also group used by dnsmasq - dip - seems to be a dial-up group. According to some source, dnsmasq may be using this group by default to get access to /etc/ppp/resolv.conf , though I'm not sure if this is needed for Fedora. If the change to running as root was intentional, it would be nice to have it briefly documented in the changelog. Version-Release number of selected component (if applicable): dnsmasq-2.40-1.fc8.x86_64 dnsmasq-2.41-0.8.fc9.x86_64 Steps to Reproduce: ps -ef | grep dnsmasq cat /proc/`/sbin/pidof -x dnsmasq`/status
I've just figured out why the use of dnsmasq --user=nobody argument has no effect in Fedora 9 - no matter what arg you give it, it always runs as root. Indeed it should be dropping privileges to nobody by default, no args required. I rebuilt the original 2.41-0.8.fc9 SRPM and the new build worked correctly, dropping privileges, so there was some problem with the original build. Stracing my new binary and comparing to an strace of the original binary, showed the problem - capset(0x20071026, 0, {CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW}) = -1 EPERM (Operation not permitted) - time(NULL) = 1232712885 + capset(0x19980330, 0, {CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW, CAP_SETGID|CAP_SETUID|CAP_NET_ADMIN|CAP_NET_RAW}) = 0 + prctl(0x8, 0x1, 0x6182, 0xb09fc0, 0x11) = 0 + setuid32(99) = 0 + capset(0x19980330, 0, {CAP_NET_ADMIN|CAP_NET_RAW, CAP_NET_ADMIN|CAP_NET_RAW, 0}) = 0 + time(NULL) = 1232712809 So, with the original binary, the capset() call fails with EPERM. When this happens, dnsmasq is unable to drop privileges, since it needs various capabilities in order to work. Notice, that the first argument to capset() is different for the old binary (0x20071026) vs the new binary (0x19980330). That value 0x20071026, corresponds to the Linux _LINUX_CAPABILITY_VERSION_2 constant in /usr/include/linux/capability.h, while 0x19980330 corresponds to _LINUX_CAPABILITY_VERSION_1. Eventually I discovered that the kernel-headers package that the original Fedora 9 build was done against, has a broken #define for the capability version, causing builds to default to the broken _LINUX_CAPABILITY_VERSION_2 version. The kernel source has this to say about v2 /* * Version 2 capabilities worked fine, but the linux/capability.h file * that accompanied their introduction encouraged their use without * the necessary user-space source code changes. As such, we have * created a version 3 with equivalent functionality to version 2, but * with a header change to protect legacy source code from using * version 2 when it wanted to use version 1. If your system has code * that trips the following warning, it is using version 2 specific * capabilities and may be doing so insecurely. * * The remedy is to either upgrade your version of libcap (to 2.10+, * if the application is linked against it), or recompile your * application with modern kernel headers and this warning will go * away. */ Thus we really do need a new build of dnsmasq in Fedora 9. It should be dropping privilegs by default, and only fails todo so because it was built against broken kernel headers. This is a potential security problem. I notice there *is* actually a new build of dnsmasq 2.45 avialable in koji for Fedora 9, but this has never been pushed out as an update for unknown reasons ?!?!
FYI, I changed the version to F9, since F10/rawhide have a newer builds which correctly drop privs, since they weren't built against broken kernel headers.
I've submitted existing 2.45-1.fc9 as an update. It's what is already in F10, and not affected by this bug. Daniel, nice work nailing this down!
dnsmasq-2.45-1.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update dnsmasq'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-1069
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Should have been closed by bodhi before: https://admin.fedoraproject.org/updates/F9/FEDORA-2009-1069