| Summary: | SELinux is preventing /usr/bin/perl from 'write' accesses on the directory /export/home/phighley/.razor. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Highley <david.m.highley> |
| Component: | selinux-policy | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 14 | CC: | dwalsh, mgrepl |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | setroubleshoot_trace_hash:73e88e2fb0047290a936b11a79ed007d1f8513ff53cfee53fd3fa23f58fbccb2 | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-01-24 15:36:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
We had this fixed before it seems. I'm also seeing a labeling issue. I run a restorecon -v -R <user direcotory>. After I see the avc I run the same command again and I see. restorecon reset /export/home/<user directory>/.razor/server.c302.cloudmark.com.conf context unconfined_u:object_r:spamc_home_t:s0->unconfined_u:object_r:razor_home_t:s0 So the labels seem to get changed. Fedora 15 has been really bad for an email server as we keep fighting the labeling issues and the support for spamassassin, razor, ana pyzor all being dropped from the policies. On my F14 machine # matchpathcon /home/phighley/.razor /home/phighley/.razor unconfined_u:object_r:spamc_home_t:s0 Razor & pyzor policies are activated again. We know they are activated again. But what should the labeling now be? We are trying to understand why the restorecon keeps getting changed, or is our labeling now screwed up from working around the previous dropping of policy issues? Well razor_home_t and spamc_home_t are the same thing in Fedora. They are aliased to each other. I think what is happening is the kernel is reporting back spamc_home_t when restorecon reads it and restorecon thinks that is different the spamc_home_t so it falsely changes it. Miroslav we should probably change the policy to label it spamc_home_t directly to eliminate this problem. |
SELinux is preventing /usr/bin/perl from 'write' accesses on the directory /export/home/phighley/.razor. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that perl should be allowed write access on the .razor directory 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 spamassassin /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:spamc_t:s0 Target Context system_u:object_r:user_home_t:s0 Target Objects /export/home/phighley/.razor [ dir ] Source spamassassin Source Path /usr/bin/perl Port <Unknown> Host (removed) Source RPM Packages perl-5.12.2-140.fc14 Target RPM Packages Policy RPM selinux-policy-3.9.7-25.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 Alert Count 10 First Seen Fri 21 Jan 2011 02:07:30 PM PST Last Seen Sat 22 Jan 2011 07:17:20 AM PST Local ID 602304da-d3a0-4c35-9368-5f949130ec89 Raw Audit Messages type=AVC msg=audit(1295709440.132:64785): avc: denied { write } for pid=21137 comm="spamassassin" name=".razor" dev=dm-2 ino=560548 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=dir spamassassin,spamc_t,user_home_t,dir,write type=SYSCALL msg=audit(1295709440.132:64785): arch=x86_64 syscall=open success=no exit=EACCES a0=4932ce0 a1=241 a2=1b6 a3=363a9273e0 items=0 ppid=21136 pid=21137 auid=4294967295 uid=1003 gid=1000 euid=1003 suid=1003 fsuid=1003 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm=spamassassin exe=/usr/bin/perl subj=system_u:system_r:spamc_t:s0 key=(null) spamassassin,spamc_t,user_home_t,dir,write #============= spamc_t ============== #!!!! The source type 'spamc_t' can write to a 'dir' of the following types: # spamass_milter_state_t, spamc_tmp_t, spamc_home_t, amavis_var_lib_t, amavis_spool_t, tmp_t, user_home_dir_t, nfs_t allow spamc_t user_home_t:dir write;