This bug is a request to change the Policy requirement that /var/run and /var/lock be absolute symlinks (to /run and /run/lock, respectively), and instead be created as relative symlinks to ../run and ../run/lock. Debian has attempted to make this change in initscripts and base-files before but rolled it back because Policy requires symlinks that cross root file system directories to be relative links.
The argument in favor of this proposal is that it makes working with chroots easier. Specifically, if one is viewing or manipulating the content of a chroot from outside the chroot, listing /chroot/var/run will actually show the system /run, and creating files or directories in /chroot/var/run will change system /run and have no effect on the chroot. I agree that this is surprising and have run into this before. Debian's current policy on this is intended to support relocation of file systems using symlinks. Specifically, it was quite common back in the day to discover that you failed to correctly anticipate file system needs when partitioning the disk and now you have a running server that's about to run out of space in /var. A common solution was to copy the contents of /var to some other partition that had more free space (/home, say) and then symlink /var to that partition. In this case, symlinks such as /var/run must be absolute, not relative. If we used relative symlinks in the above example, /var/run (actually /home/var/run), symlinked to ../run, would resolve to /home/run, which doesn't exist, probably breaking the system. The counterargument to the current policy is that doing this with symlinks is fairly obsolete and may well break other things these days (such as some scenarios where the O_BENEATH flag is used). The preferred modern approach would be to use a bind mount, which is invisible to path resolution logic and would therefore work correctly with relative symlinks as long as you encountered those symlinks via the /var path and not the /home/var path. After thinking this over for a while this morning, I think I personally find the argument for a change persuasive, but I'm nervous about it because it does break an (admittedly fairly old and arguably obsolete) common sysadmin technique. Obviously, anything we change would only be for new systems; we shouldn't change anything about existing systems that may already be configured with symlinked file systems. Perhaps documentation in the release notes would be sufficient to move forward with this change? In short, I think symlinking file systems is no longer best practice, may or may not be fully supported already (and probably isn't tested), and therefore doesn't feel like it outweighs the clarity benefits for chroots, but I'd like to get more feedback from others before we push forward with proposing a change. This feels like the sort of change that maybe we should discuss on debian-devel if it feels like we have consensus here on the Policy list. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
