Red Hat Bugzilla – Bug 584870
SELinux is preventing /bin/ln "link" access on slapd.pid.
Last modified: 2010-07-02 15:39:21 EDT
Souhrn: SELinux is preventing /bin/ln "link" access on slapd.pid. Podrobný popis: [SELinux je v tolerantním režimu. Přístup byl povolen.] SELinux denied access requested by ln. It is not expected that this access is required by ln and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Povolení přístupu: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Další informace: Kontext zdroje staff_u:system_r:initrc_t:s0 Kontext cíle staff_u:object_r:slapd_var_run_t:s0 Objekty cíle slapd.pid [ file ] Zdroj ln Cesta zdroje /bin/ln Port <Neznámé> Počítač (removed) RPM balíčky zdroje coreutils-8.4-6.el6 RPM balíčky cíle RPM politiky selinux-policy-3.7.19-1.el6 Selinux povolen True Typ politiky targeted Vynucovací režim Permissive Název zásuvného modulu catchall Název počítače (removed) Platforma Linux (removed) 2.6.32-21.el6.x86_64 #1 SMP Mon Apr 12 16:07:36 EDT 2010 x86_64 x86_64 Počet upozornění 5 Poprvé viděno Čt 22. duben 2010, 17:14:19 CEST Naposledy viděno Čt 22. duben 2010, 17:39:27 CEST Místní ID 6428fe9d-f83f-4ed1-aaa5-43397787603b Čísla řádků Původní zprávy auditu node=(removed) type=AVC msg=audit(1271950767.41:1430): avc: denied { link } for pid=31791 comm="ln" name="slapd.pid" dev=dm-1 ino=131048 scontext=staff_u:system_r:initrc_t:s0 tcontext=staff_u:object_r:slapd_var_run_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1271950767.41:1430): arch=c000003e syscall=265 success=yes exit=0 a0=ffffffffffffff9c a1=7fff548cef4d a2=ffffffffffffff9c a3=7fff548cef69 items=0 ppid=31758 pid=31791 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=3 comm="ln" exe="/bin/ln" subj=staff_u:system_r:initrc_t:s0 key=(null) Hash String generated from catchall,ln,initrc_t,slapd_var_run_t,file,link audit2allow suggests: #============= initrc_t ============== allow initrc_t slapd_var_run_t:file link;
Is there really any reason to have a hard link to a pid file in the init script? Can't we just make the pidfile /var/run/openldap/slapd.pid and get rid of all the linking stuff?
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
Keeping /var/run/openldap/slapd.pid would be my first choice as well. It is indeed better from the view of both SELinux and openldap (because it has rw access rights to /var/run/openldap/). This whole think came from QA/PM goal of making all init scripts and demons LSB compliant and their behavior similar. Can you recommend any way how to make /var/run/slapd.pid, which would be ok for SELinux?
Well making it a softlink would probably stop SELinux from complaining and probably closer to what you want anyways. LSB has a say on where pid files are stored? Why would it care... The real problem for SELinux is just complaining about the hard link.
Thanks for the advice, I'll try to make it a soft link. LSB doesn't say specifically that it wants pid file directly in /var/run, but there are some references to it in Fedora Packaging guidelines and according to QA, it is convenient to have all pid files uniformly placed.
I see no AVC running slapd via initscript on openldap-servers-2.4.19-11.el6 / RHEL6.0-20100527.2. But openldap-servers-2.4.19-9.el6 produce not AVC as well. I've manually verified that hard link is now replaced by sym link in initscript. Considering bug-fix to be successfully verified.
Red Hat Enterprise Linux Beta 2 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.