Bug 1462243

Summary: [ESXi][RHEL7.4]/etc/resolv.conf wrong context when created via vmtoolsd
Product: Red Hat Enterprise Linux 7 Reporter: Simon Reber <sreber>
Component: open-vm-toolsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: boyang, cavery, hhei, jsavanyo, ldu, leiwang, ravindrakumar, sreber, vmware-gos-qa, yacao, ybhasin
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-19 06:54:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Simon Reber 2017-06-16 13:12:53 UTC
Description of problem:

During template preparation for Red Hat Enterprise Linux 7 on VMWare, we remove `/etc/resolv.conf` as it will be created during VMWare Guest Customization anyways.

Once the template is booted and customized via VMWare Guest customization, we noticed that `/etc/resolv.conf` is created with the wrong context, which is causing other processes to write/update the file:

[root@housi ~]# ls -alZ /etc/resolv.conf
-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/resolv.conf

[root@housi ~]# ls -alZ /etc/resolv.conf
-rw-r--r--. root root system_u:object_r:net_conf_t:s0  /etc/resolv.conf

Actually `net_conf_t` is the context that should be set and not `etc_t`. Running `restorecon /etc/resolv.conf` will restore correct context and allow other processes to update the file again.


During troubleshooting we found the following process that will create `/etc/resolv.conf`:

/usr/bin/perl - -I/tmp/.vmware/linux/deploy/scripts /tmp/.vmware/linux/deploy/scripts/Customize.pl /tmp/.vmware/linux/deploy/cust.cfg

Confirmed by `auditd`

type=PATH msg=audit(06/16/2017 14:35:38.327:35) : item=1 name=/etc/resolv.conf inode=8400845 dev=fd:00 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=CREATE 
type=SYSCALL msg=audit(06/16/2017 14:35:38.327:35) : arch=x86_64 syscall=open success=yes exit=4 a0=0x13c1f10 a1=O_WRONLY|O_CREAT|O_TRUNC a2=0666 a3=0x0 items=2 ppid=745 pid=750 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=perl.orig exe=/usr/bin/perl.orig subj=system_u:system_r:vmtools_t:s0 key=resolv-file


In processes we can see the context set for the processes triggering the creation of `/etc/resolv.conf`

system_u:system_r:vmtools_t:s0  root       683     1  0 14:47 ?        00:00:00 /usr/bin/vmtoolsd
system_u:system_r:vmtools_t:s0  root       753   683  0 14:47 ?        00:00:00 /bin/bash /usr/bin/perl -I/tmp/.vmware/linux/deploy/scripts /tmp/.vmware/linux/deploy/scripts/Customize.pl /tmp/.vmware/linux/deploy/cust.cfg


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

 - open-vm-tools-10.0.5-4.el7_3.x86_64

How reproducible:

 - Always

Steps to Reproduce:
1. Install open-vm-tools and perl onto Red Hat Enterprise Linux 7
2. rm -f /etc/resolv.conf
3. stop system
4. run VMWare Guest Customization and add DNS systems in there
5. start system
6. check context set for /etc/resolv.conf via `ls -alZ /etc/resolv.conf`

Actual results:

-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/resolv.conf

Expected results:

-rw-r--r--. root root system_u:object_r:net_conf_t:s0  /etc/resolv.conf

Additional info:

Not removing `/etc/resolv.conf` in the template will prevent the issue from happening. So there is a easy way to prevent it from happening. But still, we should make sure that files created by any process always have the correct context set.

Comment 2 Richard W.M. Jones 2017-06-16 13:25:11 UTC
Ravindra, any idea about the above?

When creating files offline you need to be careful to set SELinux
labels correctly.  Unfortunately this is not trivial to do properly,
as I know first hand from libguestfs.

But in this case I'm not sure how open-vm-tools creates files, or
even if open-vm-tools is involved here at all, since AFAIK open-vm-tools
only ever runs in the context of the guest when the guest is running.

Comment 3 Ravindra Kumar 2017-06-16 16:29:08 UTC
Guest customization scripts are part of vCenter, open-vm-tools is providing the vmtoolsd daemon that help launching the scripts. I will have to open a VMware internal bug for tracking this issue.

I'm curious if this can be fixed by having vCenter scripts run additional commands like 'restorecon'?

Comment 4 Richard W.M. Jones 2017-06-16 18:11:21 UTC
Yes as long as it's all running inside the the guest you can restore
the labels on individual files by running:

  restorecon /path/to/file

or on directories (or the whole filesystem) with:

  restorecon -r /

Comment 5 Ravindra Kumar 2017-06-16 18:36:08 UTC
Thanks Rich. I have couple of more questions.

1. What is the version of VMware vCenter used in this test?
2. Is this reported by some customer or RH QA team?

Comment 6 Ravindra Kumar 2017-06-16 18:44:52 UTC
VMware internal bug is 1896920.

As the fix will not go into open-vm-tools, this bug can be resolved with necessary justification. The fix will go in VMware vCenter.

Comment 7 Richard W.M. Jones 2017-06-16 18:48:18 UTC
(In reply to Ravindra Kumar from comment #5)
> Thanks Rich. I have couple of more questions.
> 
> 1. What is the version of VMware vCenter used in this test?
> 2. Is this reported by some customer or RH QA team?

Simon, can you help with Ravindra's questions?  Looks like
the details are not in the customer case.

Comment 8 Simon Reber 2017-06-16 18:59:02 UTC
(In reply to Ravindra Kumar from comment #5)
> Thanks Rich. I have couple of more questions.
> 
> 1. What is the version of VMware vCenter used in this test?
We are testing with 6.5.0 Build 4602587 internally in Red Hat

> 2. Is this reported by some customer or RH QA team?
We are able to reproduce the issue internally but initial reporting was provided by customer. Note sure which version the customer is running though, he mentioned 6.0.

If you need more information let me know and I'll happily ask for it.

Comment 9 Ravindra Kumar 2017-06-17 11:18:29 UTC
Thanks Simon, this is good enough detail. Please feel free to resolve this bug because the fix will be in VMware vCenter product. You could inform the customer to follow up with VMware support for the fix/patch. I already shared VMware internal bug ID with you.

Comment 10 Simon Reber 2017-06-19 06:54:24 UTC
Closing this bug as the issue is tracked, VMWare internally via #1896920. As per https://bugzilla.redhat.com/show_bug.cgi?id=1462243#c9 the issue resists in VMware vCenter product and can not be fixed via `open-vm-tools`