Le lundi 9 février 2026, 10:18:37 heure normale d’Europe centrale Bastien Roucaries a écrit : > 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
Hi, Here we could replace lock -> /run/lock by run/lock In this case only one symlink should be handled > > 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.
