Bug 1462243 - [ESXi][RHEL7.4]/etc/resolv.conf wrong context when created via vmtoolsd
[ESXi][RHEL7.4]/etc/resolv.conf wrong context when created via vmtoolsd
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: open-vm-tools (Show other bugs)
7.3
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-16 09:12 EDT by Simon Reber
Modified: 2017-06-19 02:54 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-19 02:54:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3082951 None None None 2017-06-16 09:24 EDT

  None (edit)
Description Simon Reber 2017-06-16 09:12:53 EDT
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 09:25:11 EDT
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 12:29:08 EDT
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 14:11:21 EDT
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 14:36:08 EDT
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 14:44:52 EDT
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 14:48:18 EDT
(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 14:59:02 EDT
(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 07:18:29 EDT
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 02:54:24 EDT
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`

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