Bug 71571 – /var/qmail/supervise directories should be owned by root (qmail-1.03-r15)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Andy Dustman 2004-11-17 10:40:46 UTC]

supervise (from sys-apps/daemontools) cannot be started successfully from svscan:

avc:  denied  { dac_override } for pid=21763 exe=/usr/bin/supervise capability=1 scontext=system_u:system_r:svc_start_t tcontext=system_u:system_r:svc_start_t tclass=capability


Reproducible: Always
Steps to Reproduce:
1. Add a service to /service, i.e ln -s /var/qmail/supervise/qmail-send /service
2.
3.

Actual Results:  
svscan starts supervise, but supervise dies immediately.

Expected Results:  
supervise should run forever (until shut down), and execute the run script for
the service, restarting it as necessary.

I have these SELinux-related packages installed:

sec-policy/selinux-ntp-20031101
sec-policy/selinux-ucspi-tcp-20041111
sec-policy/selinux-daemontools-20041111
sec-policy/selinux-qmail-20041018
sec-policy/selinux-base-policy-20041023
sec-policy/selinux-apache-20040925
dev-python/python-selinux-2.15
sys-libs/libselinux-1.18

I find that I can fix the problem by modifying line 62 of daemontools.te from:

allow svc_start_t self:capability { kill };

to:

allow svc_start_t self:capability { dac_override kill };

and then loading the new policy.

I use policy version 17 due to the kernel version.

# emerge info
Portage 2.0.51-r3 (selinux/2004.1/x86, gcc-3.3.4, glibc-2.3.4.20040808-r1,
2.6.7-hardened-r10 i686)
=================================================================
System uname: 2.6.7-hardened-r10 i686 Pentium III (Coppermine)
Gentoo Base System version 1.4.16
Autoconf: sys-devel/autoconf-2.59-r5
Automake: sys-devel/automake-1.8.5-r1
Binutils: sys-devel/binutils-2.14.90.0.8-r1
Headers:  sys-kernel/linux26-headers-2.6.8.1
Libtools: sys-devel/libtool-1.5.2-r5
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-O2 -g -march=pentium3 -falign-labels=8 -falign-functions=64 -pipe"
CHOST="i386-pc-linux-gnu"
COMPILER=""
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/qmail/alias /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -g -march=pentium3 -falign-labels=8 -falign-functions=64 -pipe"
DISTDIR="/var/cache/distfiles"
FEATURES="autoaddcvs ccache distlocks loadpolicy sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.osuosl.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/var/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://gentoo.terry.uga.edu/gentoo-portage"
USE="berkdb crypt ncurses nls nptl pam perl python readline selinux ssl tcpd x86
zlib"

[Comment 1 petre rodan (RETIRED) 2004-11-17 13:58:51 UTC]

your avc_deny message means that a DAC permission has been overriden. 
this happens for instance when your domain receives a 'permission denied' on an action due to wrong unix permissions on a file or directory. in most cases this means that something is wrong with your setup. in your case it might be qmail's setup.

1. with your temporary fix in your policy check if all your svc services started on that machine (/service/* and /service/*/log) actually run, and are not respawned indefinitely due to a wrong permission, missing user or whatever.

2. remove that dac_override from the daemontools.te and try to pinpoint exactly which service triggers it and try to find out why (strace if needed). if you have found a service at step 1 that did not work correcty then you must fix that, and the dac_override will not be needed.

[Comment 2 Andy Dustman 2004-11-17 14:17:52 UTC]

There is only one service, and that is qmail-send. /service/qmail-send is a symbolic link to /var/qmail/supervise/qmail-send:

drwxr-xr-x  qmaill root system_u:object_r:svc_svc_t /var/qmail/supervise/qmail-send

I reverted and reloaded the policy, and changed the ownership to root, and it seems to work. I guess the problem then is that this directory is installed by qmail-1.03-r15 with the "wrong" ownership. The same applies for it's log subdirectory, and all the other qmail services in /var/qmail/supervise. There's no reason for these directories to be owned by qmaill, and in fact this is probably an error, and root ownership should not affect non-SELinux installations.

Should we just reclassify this is a qmail ebuild bug?

[Comment 3 petre rodan (RETIRED) 2004-11-18 05:24:16 UTC]

Created attachment 44220 [details, diff]
qmail ebuild diff

[Comment 4 petre rodan (RETIRED) 2004-11-18 05:28:58 UTC]

creating those dirs with qmaill is definitely a bug that came up in qmail-1.03-r15.
attached is a trivial diff to that ebuild that makes sure that dirs in /var/qmail/supervise will be owned by root.

thanks Andy for the help.

[Comment 5 Michael Hanselmann (hansmi) (RETIRED) 2005-01-15 07:34:34 UTC]

Fixed in qmail-1.03-r15 and -r16. Thanks for reporting!