Bug 205771 - avc errors when running portmap
avc errors when running portmap
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2006-09-08 09:00 EDT by Bill Peck
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-13 17:06:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Peck 2006-09-08 09:00:54 EDT
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.


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

How reproducible:

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@monad.swb.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
Comment 1 Daniel Walsh 2006-09-08 09:20:41 EDT
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.
Comment 2 Steve Dickson 2006-09-10 12:09:30 EDT

any clue?
Comment 3 Daniel Walsh 2006-09-11 11:11:41 EDT
Yes, read Comment #1
Comment 4 Steve Dickson 2006-09-12 15:46:08 EDT
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... 
Comment 5 Bill Peck 2006-09-12 16:21:21 EDT
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.
Comment 6 Steve Dickson 2006-09-13 12:21:59 EDT
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)
    (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);
Comment 7 Daniel Walsh 2006-09-13 17:06:27 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.