Bug 889705

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.