Bug 2166556

You can just email a patch to libguestfs without needing
to subscribe.  If the patch is sufficiently understandable even if it
doesn't work then I can fix it up before applying it.  Having said that
I'm not sure I understand the proposal - should we treat symlinks
as configuration files?

& should that be all symlinks or just /etc/resolv.conf?

Also the RPM format annotates configuration files ("%config") which
is very useful for dealing with upgrades - it's how RPM knows not
to blindly overwrite your local configuration when a newer package
contains an updated %config file.

Does pacman have anything similar to that?

(following reference [1] from comment#0):

      let config =
	try string_prefix "/etc/" path && (lstat path).st_kind = S_REG
	with Unix_error _ -> false in
      { ft_path = path; ft_source_path = path; ft_config = config }

So I guess the point is that we might not want to call "lstat" <https://v2.ocaml.org/api/Unix.html#VALlstat> there, but "stat" <https://v2.ocaml.org/api/Unix.html#VALstat>. IOW, if it is a symlink, dereference it, and check the referenced file's type.

Is that correct?

I don't think we can decide this ourselves generally. Many of the common utilities have specific flags for dereferencing symlinks or not:
- cp: --dereference, --no-dereference
- tar: --dereference
- find: -P, -L

This is not an easy question though, as supermin seems to use lstat in numerous places. Figuring out which ones should consider such a flag will likely not be easy.

Sorry for the late reply. Had other stuff going on.

Regarding the title change: I just took a look at the other package handlers, and this should also affect dpkg. Only rpm-based distros are unaffected.

> You can just email a patch

Except I don't know the first thing about ocaml. Plus, if I'm being honest, I moved away from virt-builder due to all the bugs. Trying to --update a debian image complains how /dev/vda does not exist. It's just more effort than it's worth.

> Does pacman have anything similar to that?

Yes, the backup property [1] in PKGBUILDs. Quick google search also reveals the Debian equivalent [2].

> should that be all symlinks or just /etc/resolv.conf?

All symlinks. While resolv.conf is the one that obviously breaks the system, /etc/systemd/system/multi-user.target.wants/ is a good example of a directory that contains symlinks as configuration. It just so happens that the files in multi-user.wants are not in the package file list, but that only suppresses the bug. /etc/mtab is another example, but that happens to not be a problem since on arch it symlinks to ../proc/self/mounts, which should exist on the final system. If someone mounted /proc to /myproc and changed their /etc/mtab on the local filesystem things would also break (I know it's an insane thing to do, but it demonstrates my point).

> So I guess the point is that we might not want to call "lstat"

No, lstat should be fine. I was talking about amending the config file check to accept both S_REG and S_LNK as configuration files to prevent configuration symlinks from the live system. However Richard makes a good point, sourcing the configuration file list from `backup` on arch, `conffiles` on debian and whatever equivalent mechanism there is on other distributions would likely be a better solution overall.

---

But I just noticed I didn't go into much detail about how the original bug in guestfs-tools happens, so:
- the preparation step, during build time for guestfs-tools, correctly detects /etc/resolv.conf as a configuration file and it correctly puts it in base.tar.gz
- but then the build step, (which for some reason happens in the live system) by guestfs-tools, does not consider /etc/resolv.conf to be a configuration file (since it is a symlink) and thus copies it to the new rootfs, overriding the /etc/resolv.conf from the base with a symlink that only makes sense in the host file system.

It'd be really nice if the supermin build step by guestfs-tools was moved to guestfs-tools build time, but that's another project. Though it would resolve the dreaded /etc/resolv.conf bug. And similar any live system mismatch issues. And remove a bunch of unnecessary dependencies.

---

[1]: https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave#Package_backup_files
[2]: https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html

> It'd be really nice if the supermin build step by guestfs-tools was moved to guestfs-tools build time, but that's another project. Though it would resolve the dreaded /etc/resolv.conf bug. And similar any live system mismatch issues. And remove a bunch of unnecessary dependencies.

You can build libguestfs like this if you want:

https://libguestfs.org/guestfs-faq.1.html#how-can-i-compile-and-install-libguestfs-without-supermin
https://libguestfs.org/guestfs-internals.1.html#fixed-appliance

However it has a twoa serious drawbacks which is why we don't do it:

 - It means you have to distribute the whole appliance, several hundreds MBs,
   when that same data is already on the disk.

 - You have to redistribute the appliance every time there's a security update.

> [1]: https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave#Package_backup_files
> [2]: https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html

I'll see if we can modify supermin to use these.

This product has been discontinued or is no longer tracked in Red Hat Bugzilla.

Reopening because Virtualization Tools has not been discontinued.