Bug 475786 - [RHEL5.3] SELinux AVC Denied: while trying to write to /.virtinst/virt-install.log
[RHEL5.3] SELinux AVC Denied: while trying to write to /.virtinst/virt-instal...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: python-virtinst (Show other bugs)
5.3
All Linux
medium Severity medium
: rc
: ---
Assigned To: Daniel Berrange
Virtualization Bugs
http://rhts.redhat.com/testlogs/38823...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-10 09:18 EST by Jeff Burke
Modified: 2009-12-14 16:09 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-23 10:41:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeff Burke 2008-12-10 09:18:28 EST
Description of problem:
 While running RHTS tests building xen guests cause avc: denied messages. This issue looks to be in an issue in the xen python libs. It SELinux is complaining about ifconfig writing to a log that doesn't exist. It is trying to write to path="/.virtinst/virt-install.log" somewhere along the line it looks like a tilda was removed or not known. I believe the intentional path is ~/.virtinst/virt-install.log

Here is a snippet from virt-install
<snip>
def main():
    options = parse_args()
    cli.setupLogging("virt-install", options.debug)
</snip>

Here is the snippet from a xen lib that gets imported
<snip>
def setupLogging(appname, debug=False):
    # set up logging
    vi_dir = os.path.expanduser("~/.virtinst")
    if not os.access(vi_dir,os.W_OK):
        try:
            os.mkdir(vi_dir)
        except IOError, e:
            raise RuntimeError, "Could not create %d directory: " % vi_dir, e
</snip>

Help on function expanduser in module posixpath:
expanduser(path)
Expand ~ and ~user constructions.  If user or $HOME is unknown,
	    do nothing.

In RHTS were not running as a user, were running from init.

Version-Release number of selected component (if applicable):
virt-manager-0.5.3-10.el5

How reproducible:
Always
  
Actual results:

type=AVC msg=audit(1228796912.386:13): avc:  denied  { append } for  pid=6191 comm="ifconfig" path="/.virtinst/virt-install.log" dev=dm-0 ino=7077890 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
type=AVC msg=audit(1228796912.386:13): avc:  denied  { read write } for  pid=6191 comm="ifconfig" path="socket:[13082]" dev=sockfs ino=13082 scontext=system_u:system_r:ifconfig_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
type=SYSCALL msg=audit(1228796912.386:13): arch=40000003 syscall=11 success=yes exit=0 a0=8a3c1e8 a1=8a3c180 a2=8a3b848 a3=0 items=0 ppid=6174 pid=6191 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="ifconfig" exe="/sbin/ifconfig" subj=system_u:system_r:ifconfig_t:s0 key=(null)

Expected results:
During an automated build of a xen guest we should not get any avc denied messages.

Additional info:
This _ONLY_ happens in the automated environment. But if the domains were set to automatically start on boot this may or may not happen.
Comment 2 Daniel Berrange 2008-12-10 10:41:49 EST
Two issues here

 - Why it is writing to /.virtinst instead of /root/.virtinst - sounds like the RHTS /etc/passwd has bogus $HOME for root user account. RHTS folks need to investigate this

 - ifconfig is inheriting the logging file handle causing the AVC

The latter is  caused by Python's logging infrastructure which fails to set the close-on-exec flag for files it opens. In this case the logfile file handle is being inherited by ifconfig

We need an equivalent fix to one we did for XenD here:

http://xenbits.xensource.com/xen-unstable.hg?rev/939f75570a15
Comment 3 Jeff Burke 2008-12-10 22:14:11 EST
RHTS is not at fault here....per say

In the original description I tried to explained why I thought virt-install was trying to write to /.virtinst rather then /root/.virtinst.

vi_dir = os.path.expanduser("~/.virtinst")

vi_dir uses expanduser(path). According to the help on expanduser

Expand ~ and ~user constructions.  If user or $HOME is unknown,
     do nothing.

When RHTS jobs run they are running from init. So the $HOME variable is unknown so it will do nothing. I spoke with Cole and he thinks we could work around the issue by first checking the $HOME variable if it is null then don't try and write to /.virtinst
Comment 4 Daniel Berrange 2008-12-11 05:24:16 EST
Erm, the code in python will read the user's home directory out of /etc/password, if $HOME isn't set

def expanduser(path):
    """Expand ~ and ~user constructions.  If user or $HOME is unknown,
    do nothing."""
    if not path.startswith('~'):
        return path
    i = path.find('/', 1)
    if i < 0:
        i = len(path)
    if i == 1:
        if 'HOME' not in os.environ:
            import pwd
            userhome = pwd.getpwuid(os.getuid()).pw_dir
        else:
            userhome = os.environ['HOME']


So, not only is $HOME unset in RHTS, but the useraccount is not setup (or /etc/passwd reads are being denied  from the SELinux context in which it runs)

We should not check $HOME in virt-install, because that's an implementation detail that 'expanduser' has. We should also *not* check for '/.virtinst' because that is a perfectly valid location for many OS which put root's $HOME on /

IMHO this is still an RHTS problem
Comment 5 Cole Robinson 2009-02-13 14:48:22 EST
What would be a valid path we can use to appease RHTS: /root/.virtinst? Maybe the simplest solution is just to export the HOME variable with RHTS tests, since it could undoubtedly cause issues with other tests.
Comment 6 Daniel Walsh 2009-02-16 12:36:38 EST
I would bet 

export HOME=/var/log/libvirt

WOuld fix the problem.

Then if ifconfig could not append to the file, it would be my problem.
Comment 7 Cole Robinson 2009-04-23 10:41:31 EDT
Hasn't been activity for a while, so closing as NOTABUG. If this is still causing issues for QA, please reopen.

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