Description of problem: jetty-8.1.0-4.fc17.noarch won't start in enforcing mode: it spews SELinux AVCs: #============= initrc_t ============== allow initrc_t http_cache_port_t:tcp_socket name_bind; allow initrc_t hugetlbfs_t:file read; allow initrc_t self:process execmem; Appears that /usr/share/jetty/bin/jetty.sh exec's Java while running under systemd's SELinux context ('initrc_t'). Shouldn't jetty/java transition to a different context (e.g., httpd_t, or a new 'jetty_t')? If so, probably need to add something so it can access /var/log/jetty. Here are the actual AVCs from /var/log/audit/audit.log when I booted with 'enforcing=0': type=SERVICE_START msg=audit(1330353641.267:29): pid=0 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg=': comm="jetty" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1330353642.590:31): avc: denied { read } for pid=747 comm="java" path=2F616E6F6E5F6875676570616765202864656C6574656429 dev="hugetlbfs" ino=17376 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:hugetlbfs_t:s0 tclass=file type=SYSCALL msg=audit(1330353642.590:31): arch=c000003e syscall=9 success=no exit=-12 a0=0 a1=200000 a2=3 a3=40022 items=0 ppid=1 pid=747 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java" subj=system_u:system_r:initrc_t:s0 key=(null) type=AVC msg=audit(1330353643.581:33): avc: denied { execmem } for pid=747 comm="java" scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=process type=SYSCALL msg=audit(1330353643.581:33): arch=c000003e syscall=9 success=yes exit=140008165998592 a0=7f5631000000 a1=270000 a2=7 a3=32 items=0 ppid=1 pid=747 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java" subj=system_u:system_r:initrc_t:s0 key=(null) type=AVC msg=audit(1330353671.705:53): avc: denied { name_bind } for pid=747 comm="java" src=8080 scontext=system_u:system_r:initrc_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket type=SYSCALL msg=audit(1330353671.705:53): arch=c000003e syscall=49 success=yes exit=0 a0=39 a1=7f563a0c74c0 a2=1c a3=7f563a0c7230 items=0 ppid=1 pid=747 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="java" exe="/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.3.x86_64/jre/bin/java" subj=system_u:system_r:initrc_t:s0 key=(null) type=SOCKADDR msg=audit(1330353671.705:53): saddr=0A001F90000000000000000000000000000000000000000000000000 Version-Release number of selected component (if applicable): jetty-8.1.0-4.fc17.noarch selinux-policy-3.10.0-93.fc17.noarch How reproducible: Every boot Steps to Reproduce: 1. install jetty 2. boot 3. Actual results: Expected results: Additional info:
This is surprising to me, since I have tested this release on SELinux-enabled machine in enforcing mode and it run fine. Though that was right after installation without reboot being involved. However that should not play a role. I have tried rebooting and the service still starts without a problem. Is there some post-install customization you have done before trying to start jetty?
Nope, at least none that I'm aware of. I just updated to this and rebooted. Here is 'ps' showing java running as initrc_t: [root@tlondon modules]# ps agxZ | grep jetty system_u:system_r:initrc_t:s0 740 ? Sl 0:19 /usr/bin/java -Djetty.home=/usr/share/jetty -Djava.io.tmpdir=/tmp -jar /usr/share/jetty/start.jar --pre=etc/jetty-logging.xml staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 3558 pts/0 S+ 0:00 grep --color=auto jetty [root@tlondon modules]# Here are java packages: [root@tlondon modules]# rpm -qa \*jdk\* java-1.6.0-openjdk-1.6.0.0-65.1.11.fc17.x86_64 java-1.7.0-openjdk-devel-1.7.0.3-2.1.fc17.1.x86_64 java-1.6.0-openjdk-debuginfo-1.6.0.0-65.1.11.fc17.x86_64 java-1.6.0-openjdk-devel-1.6.0.0-65.1.11.fc17.x86_64 java-1.7.0-openjdk-1.7.0.3-2.1.fc17.1.x86_64 [root@tlondon modules]# Here are selinux packages: [root@tlondon modules]# rpm -qa selinux\* selinux-policy-targeted-3.10.0-93.fc17.noarch selinux-policy-3.10.0-93.fc17.noarch [root@tlondon modules]#
Perhaps it is to do with 6.x to 8.x upgrade rather than more recent systemd transition. Will have a closer look
Stanisav, the reason it is working for you versus Tom, is Tom runs his machine with a much more locked down environment. Tom's system has unconfined.pp disabled meaning, he does not have any unconfined domains running on his box. jetty is running as initrc_t which is an unconfined domain, and thus works on your box. We have changed the labeling on the lates policy to run jetty under the same label as httpd. The only problem I am aware of now is that jetty needs to have the httpd_execmem boolean turned on to work and you are writing to your log files rather then appending to them. SELinux will prevent this. We might want to turn on the httpd_execmem boolean in your post install or turn it on and off when you start and stop the service.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.