Description of problem: The multihost connectahon testsuite is passing for both client and server on rawhide-20060908, but when running as the server I am seeing avc error messages from running portmap. http://rhts.lab.boston.redhat.com/cgi-bin/rhts/test_log.cgi?id=815552 Version-Release number of selected component (if applicable): rawhide-20060908 kernel-2.6.17-1.2630.fc6.i686 nfs-utils-1.0.9-5.fc6.i386 How reproducible: Everytime Additional info: This also happens with the RHEL5 Beta device eth1 left promiscuous mode audit(1157717260.967:99): dev=eth1 prom=0 old_prom=256 auid=4294967295 audit(1157717278.228:100): avc: denied { append } for pid=5049 comm="portmap" name="tmp.Tf4985" dev=sda2 ino=362932 scontext=system_u:system_r:portmap_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file audit(1157717278.340:101): avc: denied { append } for pid=5049 comm="portmap" name="tmp.Tf4985" dev=sda2 ino=362932 scontext=system_u:system_r:portmap_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file Installing knfsd (copyright (C) 1996 okir.de). SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory NFSD: starting 90-second grace period
Is portmap actually trying to write to a tmp file created in init? Or is this tmp file just grabbing STDOUT, and therefor portmap tries to talk to the TTY and this gets caught. If it is the second, it can probably be ignored since this will only happen in the test scenario.
Dan, any clue?
Yes, read Comment #1
the portmapper is opening /dev/null then dups stdin, stdout, and stderr iff the open is successful... which in this case it appears the open fails... so this is not fatal but its seems a bit over kill to stop process from opening /dev/null... imho...
steved: are you sure? I ended up changing the test as follows: service portmap start | cat > $OUTPUTFILE 2>&1 this stops the avc message from appearing.
The following routine is called like daemon(0,0) from main(): #define _PATH_DEVNULL "/dev/null" daemon(nochdir, noclose) int nochdir, noclose; { int cpid; if ((cpid = fork()) == -1) return (-1); if (cpid) exit(0); (void) setsid(); if (!nochdir) (void) chdir("/"); if (!noclose) { int devnull = open(_PATH_DEVNULL, O_RDWR, 0); if (devnull != -1) { (void) dup2(devnull, STDIN_FILENO); (void) dup2(devnull, STDOUT_FILENO); (void) dup2(devnull, STDERR_FILENO); if (devnull > 2) (void) close(devnull); } } return(0); }
These avc's have little to do with portmapper. They are basically caused by the kernel checking how stdin, stdout, stderr were opened and whether the domain (portmap_t) has the right access to these open file descriptor. If they do not the kernel closes the descriptor and hands the process a file descriptor to /dev/null. If you have redirected the stdout to a file in a random location, the kernel will check if portmap can write to that location (file_context). This is what is generating the AVC, By default the kernel would have checked a open file descriptor to tty_device_t which is dontaudited, writing to /tmp/t however is audited.