Hide Forgot
Description of problem: SELinux is preventing /usr/bin/mandb from using the 'dac_override' capabilities. ***** Plugin dac_override (91.4 confidence) suggests *********************** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. ***** Plugin catchall (9.59 confidence) suggests *************************** If you believe that mandb should have the dac_override capability 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 mandb /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:mandb_t:s0-s0:c0.c1023 Target Context system_u:system_r:mandb_t:s0-s0:c0.c1023 Target Objects [ capability ] Source mandb Source Path /usr/bin/mandb Port <Unknown> Host (removed) Source RPM Packages man-db-2.6.3-2.fc18.x86_64 Target RPM Packages Policy RPM selinux-policy-3.11.1-67.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.6.11-3.fc18.x86_64 #1 SMP Mon Dec 17 21:35:39 UTC 2012 x86_64 x86_64 Alert Count 1 First Seen 2012-12-22 19:05:08 GMT Last Seen 2012-12-22 19:05:08 GMT Local ID ee66a8af-e1d8-49d9-bee4-0ff40a1a2b0d Raw Audit Messages type=AVC msg=audit(1356203108.49:313): avc: denied { dac_override } for pid=4768 comm="mandb" capability=1 scontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tcontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tclass=capability type=SYSCALL msg=audit(1356203108.49:313): arch=x86_64 syscall=stat success=no exit=ENOENT a0=188a2b0 a1=7fffd81fb970 a2=7fffd81fb970 a3=10 items=0 ppid=4763 pid=4768 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=8 comm=mandb exe=/usr/bin/mandb subj=system_u:system_r:mandb_t:s0-s0:c0.c1023 key=(null) Hash: mandb,mandb_t,mandb_t,capability,dac_override audit2allow #============= mandb_t ============== allow mandb_t self:capability dac_override; audit2allow -R #============= mandb_t ============== allow mandb_t self:capability dac_override; Additional info: hashmarkername: setroubleshoot kernel: 3.6.11-3.fc18.x86_64 type: libreport
Could you reproduce it with Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent
This looks like some file has the wrong ownership or permissions on it that mandb_t is trying to access.
eric would it be possible in some situations to add a name field to a dac_override/dac_read_search avc, so we would have some clue what target is being denied?
maybe if you enable syscall auditting by adding a rule. I add -a exit,always -F arch=b32 -S kill -F pid=1 to /etc/audit/audit.rules as it cannot ever trigger a record, but will collect inode info. But no other way...
Yes I know, but doesn't the kernel know in some situations what the name of the file directory is when the avc is triggered? Not that path but the file name. name="shadow" for example would be a big help without turning on full auditing.
(In reply to comment #1) > Could you reproduce it with > > Turn on full auditing > # auditctl -w /etc/shadow -p w > > Try to recreate AVC. Then execute > # ausearch -m avc -ts recent Here is the output: ---- time->Thu Dec 27 19:05:05 2012 type=PATH msg=audit(1356635105.960:318): item=0 name="/home/g6avk/man" type=CWD msg=audit(1356635105.960:318): cwd="/" type=SYSCALL msg=audit(1356635105.960:318): arch=c000003e syscall=4 success=no exit=-2 a0=26422b0 a1=7ffff9f8ebe0 a2=7ffff9f8ebe0 a3=10 items=1 ppid=6106 pid=6111 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=8 comm="mandb" exe="/usr/bin/mandb" subj=system_u:system_r:mandb_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1356635105.960:318): avc: denied { dac_override } for pid=6111 comm="mandb" capability=1 scontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tcontext=system_u:system_r:mandb_t:s0-s0:c0.c1023 tclass=capability The time coincides when my system is running some standard cron jobs.
Yes, we look for name="/home/g6avk/man" # ls -dZ /home/g6avk/man
So the problem is mandb running is trying to read man files that are not owned by root and root does not have "other" access to.
(In reply to comment #7) > Yes, we look for > > name="/home/g6avk/man" > > # ls -dZ /home/g6avk/man I am puzzled as I have no such file or directory.
(In reply to comment #9) > (In reply to comment #7) > > Yes, we look for > > > > name="/home/g6avk/man" > > > > # ls -dZ /home/g6avk/man > > I am puzzled as I have no such file or directory. Sorry its been a long day, I do of course have /home/g6avk/ but cannot find anything related to "man" I've tried running the daily cron jobs manually with run-parts but the warning does not happen... assuming that is the trigger.
Which means mandb is not allowed to search through /home/g6avk ls -ld /home /home/g6avk
OK, ls -ld /home /home/g6avk drwxr-xr-x. 5 root root 4096 Jul 19 15:58 /home drwx------. 59 g6avk g6avk 4096 Dec 28 09:31 /home/g6avk I did some more checking today and noticed in my crontab file path I had: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local:/home/g6avk This file is from way back and I must of added /home/g6avk to the path when doing some tests or something years ago. I wonder if this is what has triggered this in F18
Probably. mandb is fairly new policy.
(In reply to comment #13) > Probably. mandb is fairly new policy. OK, I removed the obsolete setting "/home/g6avk" from my crontab PATH and do not get this alert anymore.