imagecustomizer: deletes /etc/resolv.conf even when it's a symlink to /run

[bureado]

imagecustomizer overrides or deletes /etc/resolv.conf in

azurelinux/toolkit/tools/pkg/imagecustomizerlib/customizeutils.go

Lines 110 to 147 in a952e5f

	// Override the resolv.conf file, so that in-chroot processes can access the network.
	// For example, to install packages from packages.microsoft.com.
	func overrideResolvConf(imageChroot *safechroot.Chroot) error {
	logger.Log.Debugf("Overriding resolv.conf file")
	imageResolveConfPath := filepath.Join(imageChroot.RootDir(), resolveConfPath)
	// Remove the existing resolv.conf file, if it exists.
	// Note: It is assumed that the image will have a process that runs on boot that will override the resolv.conf
	// file. For example, systemd-resolved. So, it isn't neccessary to make a back-up of the existing file.
	err := os.RemoveAll(imageResolveConfPath)
	if err != nil {
	return fmt.Errorf("failed to delete existing resolv.conf file: %w", err)
	}
	err = file.Copy(resolveConfPath, imageResolveConfPath)
	if err != nil {
	return fmt.Errorf("failed to override resolv.conf file with host's resolv.conf: %w", err)
	}
	return nil
	}
	// Delete the overridden resolv.conf file.
	// Note: It is assumed that the image will have a process that runs on boot that will override the resolv.conf
	// file. For example, systemd-resolved.
	func deleteResolvConf(imageChroot *safechroot.Chroot) error {
	logger.Log.Debugf("Deleting overridden resolv.conf file")
	imageResolveConfPath := filepath.Join(imageChroot.RootDir(), resolveConfPath)
	err := os.RemoveAll(imageResolveConfPath)
	if err != nil {
	return fmt.Errorf("failed to delete overridden resolv.conf file: %w", err)
	}
	return err
	}

in order to support managed resolv.conf, as in systemd-resolved (reference).

This breaks managed resolver functionality in cases where /etc is ro, notable example being when setting up a verity rootfs, which is otherwise supported by imagecustomizer.

Possible suggestions include:

1. Bypass override|deleteResolvConf() if /etc/resolv.conf exists and it's a link, or,
2. Call those functions before the scriptable customization stages run
3. Don't call those functions if /etc is calculated to be in a storage.fileSystems that is also an os.verity.dataPartition,

Both options put the user in control as they need to explicitly take an action (create a link, create resolv.conf through a script, or declare a verity partition) that should change the default behavior of resolv.conf management.

The third one is more convoluted implementation wise, because it'll also require creating the symlink, which means assuming that DNS resolution will be managed by systemd-resolved.

[bureado]

@vimish

[bureado]

Per @cwize1, it is worth noting that the finalizeCustomization scripts run after the resolv.conf file is deleted. This provides an opportunity for the user to set the file explictly.