Description of problem: BackupPC reports this error in its web interface: This CGI script (/BackupPC) is unable to connect to the BackupPC server on localhost port -1. The error was: unix connect: Permission denied. This is happening because of the following SELinux denial: [root@clio etc]# sealert -l b23b9293-83dd-4600-9d45-c53b9711e6f9 SELinux is preventing /usr/bin/perl from write access on the sock_file BackupPC.sock. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that perl should be allowed write access on the BackupPC.sock sock_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:var_run_t:s0 Target Objects BackupPC.sock [ sock_file ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host clio Source RPM Packages perl-5.18.1-288.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-106.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name clio Platform Linux clio 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 Alert Count 3 First Seen 2013-12-31 16:17:56 CET Last Seen 2013-12-31 16:20:08 CET Local ID b23b9293-83dd-4600-9d45-c53b9711e6f9 Raw Audit Messages type=AVC msg=audit(1388503208.129:4541): avc: denied { write } for pid=5889 comm="BackupPC_Admin." name="BackupPC.sock" dev="tmpfs" ino=201094 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file type=SYSCALL msg=audit(1388503208.129:4541): arch=x86_64 syscall=connect success=no exit=EACCES a0=3 a1=28ed3b0 a2=6e a3=7fff813d8e90 items=0 ppid=1899 pid=5889 auid=4294967295 uid=48 gid=48 euid=498 suid=498 fsuid=498 egid=48 sgid=48 fsgid=48 ses=4294967295 tty=(none) comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null) Hash: BackupPC_Admin.,httpd_t,var_run_t,sock_file,write Version-Release number of selected component (if applicable): BackupPC-3.2.1-15.fc20.x86_64 selinux-policy-3.12.1-106.fc20.noarch How reproducible: Always. Steps to Reproduce: 1. Start BackupPC. 2. Visit the web interface. Actual results: Web interface can't connect to the socket. Expected results: Web interface should show normal BackupPC content. Additional info: This stopped working after I upgraded from Fedora 18 to Fedora 20.
Could you execute # semodule -i /usr/share/selinux/packages/BackupPC/BackupPC.pp # fixfiles -R BackupPC restore To make sure everything is labeled correctly. On Rawhide I am seeing semodule -i /usr/share/selinux/packages/BackupPC/BackupPC.pp libsepol.permission_copy_callback: Module BackupPC depends on permission kill in class service, not satisfied (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed!
(In reply to Daniel Walsh from comment #1) > Could you execute > # semodule -i /usr/share/selinux/packages/BackupPC/BackupPC.pp > # fixfiles -R BackupPC restore > > To make sure everything is labeled correctly. > > On Rawhide I am seeing > > semodule -i /usr/share/selinux/packages/BackupPC/BackupPC.pp > > libsepol.permission_copy_callback: Module BackupPC depends on permission > kill in class service, not satisfied (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! I don't get any message from running 'semodule -i'. 'fixfiles' takes more than 12 hours, but completes successfully. After that, I get this denial: [root@clio uckelman]# sealert -l 72604351-c91d-42bf-98d6-b3fb750268fa SELinux is preventing /usr/bin/perl from read access on the file backups. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that perl should be allowed read access on the backups file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:init_var_lib_t:s0 Target Objects backups [ file ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host clio Source RPM Packages perl-5.18.1-288.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-106.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name clio Platform Linux clio 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 Alert Count 23 First Seen 2013-12-31 16:43:53 CET Last Seen 2014-01-07 14:33:25 CET Local ID 72604351-c91d-42bf-98d6-b3fb750268fa Raw Audit Messages type=AVC msg=audit(1389101605.534:468): avc: denied { read } for pid=5315 comm="BackupPC_Admin." name="backups" dev="dm-0" ino=99745819 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1389101605.534:468): arch=x86_64 syscall=open success=no exit=EACCES a0=1805f10 a1=0 a2=1b6 a3=0 items=0 ppid=5299 pid=5315 auid=4294967295 uid=48 gid=48 euid=498 suid=498 fsuid=498 egid=48 sgid=48 fsgid=48 ses=4294967295 tty=(none) comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null) Hash: BackupPC_Admin.,httpd_t,init_var_lib_t,file,read
And now I'm getting the original denial again: [root@clio selinux]# sealert -l 3e97ee66-81c7-4140-a693-fee945512e71 SELinux is preventing /usr/bin/perl from connectto access on the unix_stream_socket /run/BackupPC/BackupPC.sock. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that perl should be allowed connectto access on the BackupPC.sock unix_stream_socket by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:system_r:init_t:s0 Target Objects /run/BackupPC/BackupPC.sock [ unix_stream_socket ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host clio Source RPM Packages perl-5.18.1-288.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-106.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name clio Platform Linux clio 3.12.5-302.fc20.x86_64 #1 SMP Tue Dec 17 20:42:32 UTC 2013 x86_64 x86_64 Alert Count 4 First Seen 2014-01-07 14:40:52 CET Last Seen 2014-01-07 14:41:10 CET Local ID 3e97ee66-81c7-4140-a693-fee945512e71 Raw Audit Messages type=AVC msg=audit(1389102070.875:473): avc: denied { connectto } for pid=5410 comm="BackupPC_Admin." path="/run/BackupPC/BackupPC.sock" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket type=SYSCALL msg=audit(1389102070.875:473): arch=x86_64 syscall=connect success=no exit=EACCES a0=3 a1=11faa60 a2=6e a3=7fff61132fa0 items=0 ppid=3394 pid=5410 auid=4294967295 uid=48 gid=48 euid=498 suid=498 fsuid=498 egid=48 sgid=48 fsgid=48 ses=4294967295 tty=(none) comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null) Hash: BackupPC_Admin.,httpd_t,init_t,unix_stream_socket,connectto
ps -eZ | grep init_t
[uckelman@clio ~]$ ps -eZ | grep init_t system_u:system_r:init_t:s0 1 ? 00:00:08 systemd system_u:system_r:init_t:s0 719 ? 00:00:04 BackupPC system_u:system_r:init_t:s0 720 ? 00:03:03 BackupPC_trashC system_u:system_r:init_t:s0 2120 ? 00:00:00 systemd system_u:system_r:init_t:s0 2124 ? 00:00:00 (sd-pam) system_u:system_r:init_t:s0 2774 ? 00:00:00 systemd system_u:system_r:init_t:s0 2776 ? 00:00:00 (sd-pam)
The bug then is that BachupPC is running as init_t? No idea why. ls -lZ PATHTO/BackupPC
I couldn't say why BackupPC would be running as init_t. It's not something I changed, at least not intentionally. [root@clio uckelman]# ls -lZ /var/lib/BackupPC drwxr-x---. backuppc root system_u:object_r:var_lib_t:s0 ./ drwxr-xr-x. root root system_u:object_r:var_lib_t:s0 ../ -rw-------. backuppc backuppc unconfined_u:object_r:var_lib_t:s0 .bash_history drwx------. backuppc backuppc system_u:object_r:ssh_home_t:s0 .ssh/ drwxr-x---. backuppc root system_u:object_r:var_lib_t:s0 cpool/ drwxr-x---. backuppc root system_u:object_r:var_lib_t:s0 pc/ drwxr-x---. backuppc root system_u:object_r:var_lib_t:s0 pool/ drwxr-x---. backuppc root system_u:object_r:var_lib_t:s0 trash/ Note that this is *after* running 'rectorecon -R /var/lib/BackupPC', which got BackupPC working again. (Permitting the access as suggested by sealert was necessary, but not sufficient.)
Ok, the problem the BackupPC policy has allow httpd_t initrc_t:unix_stream_socket connectto; which shows us it is supposed to run as initrc_t. But now we see init_t because of systemd. Anyways, the BackupPC policy should be fixed at all. Joel, what does # ps -efZ | grep init_t
[root@clio uckelman]# ps -efZ | grep init_t system_u:system_r:init_t:s0 root 1 0 0 08:51 ? 00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 22 system_u:system_r:init_t:s0 backuppc 718 1 0 08:51 ? 00:00:00 /usr/bin/perl /usr/share/BackupPC/bin/BackupPC -d system_u:system_r:init_t:s0 backuppc 719 718 0 08:51 ? 00:00:00 /usr/bin/perl /usr/share/BackupPC/bin/BackupPC_trashClean system_u:system_r:init_t:s0 root 2049 1 0 09:01 ? 00:00:00 /usr/lib/systemd/systemd --user system_u:system_r:init_t:s0 root 2052 2049 0 09:01 ? 00:00:00 (sd-pam) system_u:system_r:init_t:s0 uckelman 2757 1 0 12:24 ? 00:00:00 /usr/lib/systemd/systemd --user system_u:system_r:init_t:s0 uckelman 2759 2757 0 12:24 ? 00:00:00 (sd-pam) unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 2802 2787 0 12:24 pts/0 00:00:00 grep --color=auto init_t
I meant the path to the binaries not the content. restorecon -R -v /usr/sbin and /usr/bin Should change some labels.
> I meant the path to the binaries not the content. Ah, sorry. [root@clio uckelman]# ls -lZ /usr/share/BackupPC/bin/BackupPC -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /usr/share/BackupPC/bin/BackupPC* > restorecon -R -v /usr/sbin and /usr/bin Should this be restorecon -R -v /usr/share/BackupPC instead, then?
The point is there is missing policy [Service] Type=oneshot User=backuppc Group=backuppc ExecStart=/usr/share/BackupPC/bin/BackupPC -d RemainAfterExit=yes and /usr/share/BackupPC/bin/BackupPC is labeled as bin_t. This is a reason why we see init_t.
What needs to happen to get this fixed?
Lukas, could you help with a working policy for BackupPC?
*** Bug 1055736 has been marked as a duplicate of this bug. ***
*** Bug 998282 has been marked as a duplicate of this bug. ***
Still no update on this issue? BackupPC web interface is unusable with selinux turned on ...
Seeing this as well after fedup'ing from 19 to 20.
The latest update seems to fix most of the issues but I still can't access log files: SELinux is preventing /usr/bin/perl from open access on the file . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that perl should be allowed open access on the file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:init_var_lib_t:s0 Target Objects [ file ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host hobbes.localdomain Source RPM Packages perl-5.18.2-289.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-122.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name hobbes.localdomain Platform Linux hobbes.localdomain 3.13.5-202.fc20.x86_64 #1 SMP Mon Mar 3 19:08:00 UTC 2014 x86_64 x86_64 Alert Count 5 First Seen 2014-03-08 15:11:54 CST Last Seen 2014-03-10 21:26:29 CDT Local ID d618ac22-0226-416a-962d-f2fa261f617c Raw Audit Messages type=AVC msg=audit(1394504789.292:22567): avc: denied { open } for pid=21028 comm="BackupPC_Admin." path="/var/lib/BackupPC/pc/localhost/XferLOG.bad.z" dev="dm-3" ino=3670031 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=file type=SYSCALL msg=audit(1394504789.292:22567): arch=x86_64 syscall=open success=no exit=EACCES a0=1162af0 a1=0 a2=1b6 a3=0 items=0 ppid=25133 pid=21028 auid=4294967295 uid=48 gid=48 euid=988 suid=988 fsuid=988 egid=48 sgid=48 fsgid=48 ses=4294967295 tty=(none) comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null) Hash: BackupPC_Admin.,httpd_t,init_var_lib_t,file,open
The last update did not change anything for me. Error: Unable to connect to BackupPC server This CGI script (/BackupPC) is unable to connect to the BackupPC server on localhost port -1. The error was: unix connect: Permission denied. Perhaps the BackupPC server is not running or there is a configuration error. Please report this to your Sys Admin. This was working just fine some time ago. It is really impossible having selinux enforced.
Created attachment 876881 [details] BackupPC policy
Created attachment 876891 [details] file contexts
Could you please try to download these policy files and run # make -f /usr/share/selinux/devel/Makefile BackupPC.pp # semodule -i BackupPC.pp # restorecon -Rv /var/lib/BackupPC /var/run/BackupPC /var/log/BackupPC /etc/BackupPC /usr/share/BackupPC/bin/BackupPC and re-test it? Thank you.
That seemed to fix the web interface for me but one new problem I've noted that I have no idea if it's a SELinux problem or not. After upgrading from F19 to F20 it will not back up any hosts because it thinks the pings have failed. I can log on as the backuppc user and ping any host fine. If it's not selinux related let me know and I'll open a new ticket.
Thank you for testing. Does it work in permissive mode? #setenforce 0 If yes, then it's not SELinux issue.
I do not have the ability to test this policy update. I also did not see feedback from testers whether the policy resolved the issue. Are you looking for a scratch or test build to facilitate testing?
Yes I believe a scratch build would be better for people.
I would have to do a complete reinstall (and clear out any SELinux tweaks I've done) to be sure, but this policy at least improves functionality if not solves all the problems. I think it's worth a release.
With selinux-policy-3.12.1-135, I no longer have the socket problem, but I still have a problem with files under /var/lib/BackupPC getting labelled so that the web interface can't read them. When I do a 'restorecon -rv /var/lib/BackupPC', I see a lot of this: > context system_u:object_r:init_var_lib_t:s0->system_u:object_r:var_lib_t:s0 I think this is still the same problem discussed in Comment #12.
The fix from comment #23 improved a lot, but I still get an initial: This CGI script (/BackupPC) is unable to connect to the BackupPC server on localhost port -1. But at least is just one round of sudo grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol sudo semodule -i mypol.pp after that ...
Description of problem: 1) Start httpd server if it is not alraedy running 2) Point web browser to localhost/backuppc 3) Fill the user and pawword you defined for the admin user of BackuppPC 4) You get the message: "This CGI script (/backuppc) is unable to connect to the BackupPC server on localhost port -1. The error was: unix connect: Permission denied. Perhaps the BackupPC server is not running or there is a configuration error. Please report this to your Sys Admin." 5) The Selinux alart browser pops up and tells you there is a problem with perl trying to access a unit socket it isn't allowed to. Additional info: reporter: libreport-2.2.2 hashmarkername: setroubleshoot kernel: 3.14.6-200.fc20.x86_64 type: libreport
(In reply to Paulo Roma Cavalcanti from comment #30) > The fix from comment #23 improved a lot, > but I still get an initial: > > This CGI script (/BackupPC) is unable to connect to the BackupPC server on > localhost port -1. > > But at least is just one round of > > sudo grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol > sudo semodule -i mypol.pp > > after that ... And did it work in permissive mode?
The originally reported problem is still an issue for me on a fresh (20140721) Fedora 20 install with: selinux-policy-targeted-3.12.1-177.fc20.noarch BackupPC-3.3.0-2.fc20.x86_64 As noted above, systemd still runs /usr/share/BackupPC/bin/BackupPC (labeled bin_t) as init_t but BackupPC.te allows only initrc_t: allow httpd_t initrc_t:unix_stream_socket connectto; This can be patched: cd /tmp echo "avc: denied { connectto } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket" \ | audit2allow -M BackupPC.patch semodule -i BackupPC.patch.pp One can then connectto the backend through the web interface but it won't backup my localhost because of the ... https://bugzilla.redhat.com/show_bug.cgi?id=1079437 ... issue with an empty PingPath After fixing that, I was able to "Start Incr Backup" through the web interface. However, after the job completed, the web interface was unable to report the backups summary for this host This PC has never been backed up!! This, apparently, is due to a relabeling of the updated backups summary file ls -Z /var/lib/BackupPC/pc/localhost/backups -rw-r-----. backuppc backuppc system_u:object_r:init_var_lib_t:s0 /var/lib/BackupPC/pc/localhost/backups This can be fixed by relabeling this file ... restorecon -v /var/lib/BackupPC/pc/localhost/backups restorecon reset /var/lib/BackupPC/pc/localhost/backups context system_u:object_r:init_var_lib_t:s0->system_u:object_r:var_lib_t:s0 ... but then one cannot browse/access any of the new files backed up because of similar mislabeling. This takes a long time to fix this way: restorecon -R -v /var/lib/BackupPC/
... Rather than constantly/laboriously relabel, patch BackupPC SELinux policy to allow some more ... cd /tmp echo -e " avc: denied { connectto } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket avc: denied { getattr } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=file avc: denied { read } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=file avc: denied { read } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=dir avc: denied { open } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=file avc: denied { ioctl } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=file avc: denied { open } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=dir avc: denied { search } scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:init_var_lib_t:s0 tclass=dir " | audit2allow -M BackupPC.patch semodule -i BackupPC.patch.pp
Still having the labelling problem with BackupPC-3.3.0-2.fc20.x86_64 and selinux-policy-3.12.1-177.fc20.noarch.
(In reply to Miroslav Grepl from comment #27) > Yes I believe a scratch build would be better for people. Is there a chance to do it with the attached policy which I created? We can not move forward without that.
Scratch builds follow: rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=7236321 F21: http://koji.fedoraproject.org/koji/taskinfo?taskID=7236335 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=7236341 F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=7236347
I'm relabelling now and will install the F20 scratch shortly. I should know in a day or so (after the next batch of backups have occurred) whether the change has been effective.
With the scratch build, I'm seeing what looks like the original SELinux denial once again: SELinux is preventing /usr/bin/perl from write access on the sock_file . ***** Plugin catchall (100. confidence) suggests ************************** If you believe that perl should be allowed write access on the sock_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep BackupPC_Admin. /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:var_run_t:s0 Target Objects [ sock_file ] Source BackupPC_Admin. Source Path /usr/bin/perl Port <Unknown> Host clio Source RPM Packages perl-5.18.2-289.fc20.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-180.fc20.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name clio Platform Linux clio 3.15.10-200.fc20.x86_64 #1 SMP Thu Aug 14 15:39:24 UTC 2014 x86_64 x86_64 Alert Count 1 First Seen 2014-08-25 20:43:11 CEST Last Seen 2014-08-25 20:43:11 CEST Local ID e89df1f9-42c4-4b4b-92ed-8d39ee733e6d Raw Audit Messages type=AVC msg=audit(1408992191.133:459): avc: denied { write } for pid=6036 comm="BackupPC_Admin." name="BackupPC.sock" dev="tmpfs" ino=45682 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file type=SYSCALL msg=audit(1408992191.133:459): arch=x86_64 syscall=connect success=no exit=EACCES a0=3 a1=2ca1490 a2=6e a3=7fffe806c060 items=0 ppid=3317 pid=6036 auid=4294967295 uid=48 gid=48 euid=997 suid=997 fsuid=997 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm=BackupPC_Admin. exe=/usr/bin/perl subj=system_u:system_r:httpd_t:s0 key=(null) Hash: BackupPC_Admin.,httpd_t,var_run_t,sock_file,write
This is the policy I needed (over selinux-policy-3.12.1-180) to stop denials with the scratch build: module backuppc_1047537_ii 1.0; require { type var_run_t; type init_t; type BackupPC_var_run_t; type init_var_lib_t; type httpd_t; class sock_file write; class unix_stream_socket connectto; class file lock; class dir read; } #============= httpd_t ============== allow httpd_t BackupPC_var_run_t:sock_file write; allow httpd_t init_t:unix_stream_socket connectto; allow httpd_t init_var_lib_t:dir read; allow httpd_t init_var_lib_t:file lock; allow httpd_t var_run_t:sock_file write;
Just to be sure how /usr/share/BackupPC/bin/BackupPC is labeled? ls -Z /usr/share/BackupPC/bin/BackupPC
[uckelman@clio ~]$ ls -Z /usr/share/BackupPC/bin/BackupPC -rwxr-xr-x. root root system_u:object_r:BackupPC_exec_t:s0 /usr/share/BackupPC/bin/BackupPC*
Ok and # ps -efZ |grep BackupPC
[root@clio ~]# ps -efZ |grep BackupPC system_u:system_r:BackupPC_t:s0 backuppc 710 1 0 08:11 ? 00:00:00 /usr/bin/perl /usr/share/BackupPC/bin/BackupPC -d system_u:system_r:BackupPC_t:s0 backuppc 716 710 0 08:11 ? 00:00:07 /usr/bin/perl /usr/share/BackupPC/bin/BackupPC_trashClean unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 2939 2920 0 20:19 pts/0 00:00:00 grep --color=auto BackupPC
I found that I was able to get the CGI connecting to the server with Miroslav's policy files with a single addition to the .te file: allow httpd_t BackupPC_var_run_t:sock_file write;
Ok. It's much better. Scott, how does # ps -efZ |grep BackupPC for you if you run BackupPC.
Lukas, could you create a patch for BackupPC policy which could be released by BackupPC?
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora 'version' of '20'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 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 this bug is closed as described in the policy above. 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.
Is this still a problem? I recently logged into the admin interface and left SELinux enforcing and didn't run into any problems on f21...
I don't see this happening in F22. If it recurs, I'll let you know.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.