There appears to be a generic problem with "pidof -c" under SELinux
enforcing which has the side-effect of confusing some of the init.d
scripts.
In particular, the following services - at least - fail to shut down or
report status cleanly:
acpid
hidd
vsftpd
smartd
autofs
mcstrans
syslog-ng ( but not syslogd .. )
The common feature is that these daemons lack a corresponding
/var/run/<daemonname>.pid; in the case of syslog-ng, of course, the real
pid has the "wrong" name.
During shutdown, /etc/init.d/functions:killproc() searches for the
pidfile, and if it fails to find one, it searches for a pid with a
matching exec name via the __pids_pidof() function.
...
# Output PIDs of matching processes, found using pidof
__pids_pidof() {
pidof -c -o $$ -o $PPID -o %PPID -x "$1" || \
pidof -c -o $$ -o $PPID -o %PPID -x "${1##*/}"
}
...
When invoked in SELinux permissive, all is well, and the correct pid is
located, but under enforcing, ( selinux-policy-strict-2.4.6-27 in my
case), "pidof -c" returns a null string. This in turn, causes killproc
to assume that the service is dead.
FWIW, FC4/strict/enforcing is Ok where pidof has a -c option, whilst
RHEL4 doesn't appear to have a -c option to pidof anyway.
The latest pidof appears to use readlink() to compare the value
of /proc/<pid>/exe for any matching pids - older pidof's used stat().
Needless to say, logs don't show any AVC's when I try to run the rogue
pidof calls.
By way of example, one can read the basic process list from sysadm_t,
and then show that pidof -c -x fails where pidof -x works. Similarly,
I've used run_init to emulate the behaviour of the boot scripts running
pidof:
[root@topaz ~]# ps axZ | grep smartd
system_u:system_r:fsdaemon_t 2871 ? S
0:00 /usr/sbin/smartd -q never
staff_u:sysadm_r:sysadm_t 3375 pts/0 R+ 0:00 grep smartd
[root@topaz ~]#
[root@topaz ~]# pidof -x /usr/sbin/smartd
2871
[root@topaz ~]# pidof -x smartd
2871
[root@topaz ~]#
[root@topaz ~]# pidof -c -x /usr/sbin/smartd
[root@topaz ~]# pidof -c -x smartd
[root@topaz ~]# run_init pidof -c -x /usr/sbin/smartd
Authenticating root.
Password:
[root@topaz ~]#
[root@topaz ~]# run_init pidof -x /usr/sbin/smartd
Authenticating root.
Password:
2871
[root@topaz ~]#
As a variant on these tests, I've tried to directly ls and readlink the
exe in question; ls fails to read the symlink and errors, whilst
readlink silently returns with a null.
[root@topaz ~]# ls -ldZ /proc/2871/exe
ls: cannot read symbolic link /proc/2871/exe: Permission denied
lrwxrwxrwx root root system_u:system_r:fsdaemon_t /proc/2871/exe
[root@topaz ~]# run_init ls -ldZ /proc/2871/exe
Authenticating root.
Password:
lrwxrwxrwx root root system_u:system_r:fsdaemon_t /proc/2871/exe
[root@topaz ~]#
[root@topaz ~]# run_init ls -lZ /proc/2871/exe
Authenticating root.
Password:
ls: /proc/2871/exe: Permission denied
[root@topaz ~]# readlink /proc/2871/exec
[root@topaz ~]#
[root@topaz ~]# run_init readlink /proc/2871/exec
Authenticating root.
Password:
[root@topaz ~]#
As a workround for the present, I've simply removed the -c option
from /etc/init.d/functions:__pids_pidof()
I'm currently running:
selinux-policy-strict-2.4.6-27.fc6
kernel-2.6.18-1.2869
SysVinit-2.86-14
Should this be logged as a bug under SELinux policy or SysVinit?
Does this bug affect targeted policy as well?
Is there some simple extra permission which could be granted to initrc_t
and sysadm_t which would let them perform readlink /proc/<pid>/exe, and
hence pidof -c ?
--
Ted Rule
Director, Layer3 Systems Ltd
W: http://www.layer3.co.uk/
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
