Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 657566

Summary: Unrelated ifconfig AVC failures
Product: [Retired] Beaker Reporter: Petr Šplíchal <psplicha>
Component: beahAssignee: Marian Csontos <mcsontos>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 0.6CC: bpeck, dcallagh, dwalsh, fge, jscotka, mcsontos, mfranc, mmalik, ohudlick, rmancy, sassmann, zmraz
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-19 19:50:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 668854    
Bug Blocks:    

Description Petr Šplíchal 2010-11-26 14:04:07 UTC
Description of problem:

When running a multihost jobs the following AVC failures appear:

    type=AVC msg=audit(1290777263.722:20): avc:  denied  { read
    write } for  pid=4053 comm="ifconfig" path="socket:[11818]"
    dev=sockfs ino=11818 scontext=system_u:system_r:ifconfig_t:s0
    tcontext=system_u:system_r:initrc_t:s0 tclass=udp_socket

The test itself does not run any "ifconfig" command and was
working fine recently.

Version-Release number of selected component (if applicable):
0.5.62

https://beaker.engineering.redhat.com/jobs/34493
https://beaker.engineering.redhat.com/jobs/34494
https://beaker.engineering.redhat.com/jobs/34486

Comment 2 Marian Csontos 2010-11-29 15:21:17 UTC
This is caused by os.popen not closing open file descriptors.

Comment 3 Milos Malik 2010-12-02 14:26:07 UTC
Seen on 3 different RHEL-5.6-Server-Snapshot-2.0 machines with selinux-policy-2.4.6-297.el5:
----
time->Thu Dec  2 09:00:35 2010
type=SYSCALL msg=audit(1291298435.552:24): arch=c0000032 syscall=1033 success=yes exit=0 a0=60000000000219e0 a1=6000000000020e40 a2=60000000000209b0 a3=6000000000018c7c items=0 ppid=2627 pid=2802 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="ifconfig" exe="/sbin/ifconfig" subj=system_u:system_r:ifconfig_t:s0 key=(null)
type=AVC msg=audit(1291298435.552:24): avc:  denied  { read write } for  pid=2802 comm="ifconfig" path="socket:[13274]" dev=sockfs ino=13274 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=udp_socket
----

Comment 4 Milos Malik 2010-12-02 14:27:31 UTC
How to Reproduce:
Just reboot the machine and you will see the AVC.

Comment 5 Marian Csontos 2010-12-02 14:45:38 UTC
This issue is still there and `ausearch -m AVC` will show the errors (and it's there even without reboot.)

But you should not see them in your results - it's now _again_ masked by AVC filters as it was before unless different locale was used (which is now fixed.)

If you do see them, comment on the BZ please.

Comment 6 Petr Šplíchal 2010-12-10 14:28:10 UTC
(In reply to comment #5)

> But you should not see them in your results - it's now _again_
> masked by AVC filters as it was before unless different locale
> was used (which is now fixed.)

AVC failures appeared again in the latest tier test run, and they
affect the final test result, which is still FAIL:

https://beaker.engineering.redhat.com/tasks/executed?task=%2FCoreOS%2Fhttpd%2FMultihost%2Fstress&result_id=4&job_id=38466

Comment 7 Daniel Walsh 2010-12-10 16:43:08 UTC
Is the test doing the os.popen?

Comment 8 Bill Peck 2010-12-10 16:53:18 UTC
Marian can asnwer for sure.  But I'm pretty sure its when we use a certain python module.  If memory serves me right its the python-uuid module?

Comment 9 Marian Csontos 2010-12-10 22:27:10 UTC
Yes, it's the python-uuid which is used by harness.

Comment 10 Daniel Walsh 2010-12-13 14:51:08 UTC
Bill lets add some policy to ignore this.

Could you see if this compiles into your policy.
init_dontaudit_script_leaks(domain)

Comment 11 Marian Csontos 2011-01-25 10:19:59 UTC
This effect will go away with using uuid4 instead of uuid1: Bug 668854.

I may want in the future to return to uuid1, as it exposes some useful bits - machine where uuid was built and timestamp which is sometimes useful at diagnosing but for now I am closing this as duplicate.

*** This bug has been marked as a duplicate of bug 668854 ***

Comment 12 Miroslav Franc 2011-05-17 09:36:46 UTC
The issue is not gone. It's still causing unrelated avc messages and creates bogus failures during testing.

https://beaker.engineering.redhat.com/tasks/executed?task=/tools/glibc/Regression/bz585674-free-race-in-mcheck-hooks&job_id=85765

Version - 0.6.10

Comment 13 Marian Csontos 2011-05-17 13:12:04 UTC
The bug is really fixed. The problem is el5 on ppc64 is using wrong repo
I will try to get that fixed in 0.6.11.

Leaving the bug opened for tracking.