Le dimanche 8 février 2026, 20:36:32 heure normale d’Europe centrale Russ Allbery a écrit : > 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.
I think we should update and ask a debconf question during upgrade if we detect /var being a symlink, that is the only problematic case, and upgrade if not the case during preinst Moreover it will allow sysadmin possibility to bail out and use bind mount if we detect a symlink > 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, And docker and so on > 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. > rouca
signature.asc
Description: This is a digitally signed message part.
