Issue/Introduction

GuestTools rewrites /etc/hosts when synchronizing the hostname. The confirmed implementation creates /etc/hosts.tmp and then uses rename to replace the original file. When the process uses umask=077, the new file has permissions 0600 because the original file mode is not preserved.

Symptoms

• After a virtual machine is created from a template through a third-party API and its hostname is synchronized, /etc/hosts changes from 0644 to 0600.
• A comparison VM created on the page might remain at 0644 because it did not follow the same hostname synchronization path.
• Regular users or non-root services might be unable to read /etc/hosts.

Environment

Verified on ZSphere 4.10.19 and CentOS 7. Cite this article for other Linux systems or versions only when the same call path and evidence are present.

Possible causes

First confirm the permission change and when it occurred, and then correlate it with hostname synchronization and GuestTools logs. Ownership, ACL, xattr, and SELinux context are risks that must be evaluated; do not state that they changed without evidence.

Issue classification

• Type: Product bug.
• Known issue: Yes. Customer issue TIC-6130 is Closed/Done; product bug ZSV-12764 remained Open/P2 as of 2026-08-06.
• Root cause: write_hosts_file() creates a new temporary inode and replaces the original file without preserving its mode. umask 077 gives the new file mode 0600.
• Confirmed impact: Read access for regular users/non-root processes. Changes to ownership, ACL, xattr, or SELinux are unverified potential impacts.
• Confidence: High.

Resolution

Check 1: Read the current file metadata

• Read-only commands:

  stat -c 'mode=%a owner=%U:%G inode=%i mtime=%y file=%n' /etc/hosts
  getfacl -p /etc/hosts 2>/dev/null
  ls -lZ /etc/hosts 2>/dev/null

• If mode=600: Confirm the symptom and correlate it with the hostname synchronization time.
• If mode=644/640 or another customer baseline value: The issue is not currently reproduced. Obtain historical logs or audit evidence before classifying it.
• If ACL/SELinux is abnormal: Record it as a separate impact; do not infer it from the mode alone.

Check 2: Verify the trigger path

• Purpose: Confirm that the permission change is related to hostname synchronization rather than a security-hardening script.
• Read-only commands:

  hostnamectl status
  journalctl --since '-2 hours' | grep -Ei 'hostname|guesttools|zs-tools|hosts'

• If the /etc/hosts mtime matches the hostname synchronization/creation time: This supports ZSV-12764.
• If a security-hardening, configuration-management, or custom script also rewrites the file: Competing writers exist. Audit them before determining the root cause.

Check 3: Confirm the application impact

• Read-only commands:

  getent hosts "$(hostname)"
  namei -l /etc/hosts

• If root succeeds but a regular application user cannot resolve names or read the file: This is consistent with the impact of mode 0600.
• If name resolution succeeds: This does not mean that the permissions are correct. Evaluate them against the security baseline.

Recommended actions

First record the original metadata with stat/getfacl/ls -Z. After the customer confirms that the standard is root:root 0644, an administrator can restore the permissions. If ownership, ACL, or the SELinux context is also abnormal, restore each according to the customer baseline. Then verify read access and name resolution using a regular application account. Use the metadata saved before the operation as the rollback reference; do not overwrite all metadata without checking the baseline.

Long-term solution

Track ZSV-12764: use a unique temporary file; preserve the original mode, uid/gid, ACL/xattr/SELinux context after writing; replace it atomically; and add tests for umask, concurrency, read-only, and immutable conditions.

Additional information

When to escalate

• The file has custom ownership, ACL, SELinux labels, or the immutable attribute.
• A production application already has name-resolution or startup failures.
• The permissions change again after restoration.
• You need the fixed version or a temporary patch.

Information to collect

ZSphere/GuestTools/OS versions, creation method, hostname synchronization time, the output of the three read-only command groups, GuestTools logs, and the security-hardening/configuration-management inventory.

Related issues

• TIC-6130, Closed/Done.
• ZSV-12764, Open/P2.
• Status verified on 2026-08-06.