XPost: linux.debian.policy   
   From: rouca@debian.org   
   Copy: 1039979@bugs.debian.org   
      
   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   
      
      
      
   -----BEGIN PGP SIGNATURE-----   
      
   iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmmJplEACgkQADoaLapB   
   CF8KrQ/9HyM8Bdab1c5O8u4b6f1Ix5GP2PuhcRxh5s3dlBk1dQ58L5wc6E2TRjg1   
   +6fTXqoI6a/j4RB1Q6MaNK4UN1W1RJQq5wTB8ACgU9etypiaLruvgHf1IC2344/P   
   G9Xx65Nsz8ei9I70qtnBHn12nyHt+nqK/Z2ZJ45egGEWkkRIn3XxXkkyMaigzxyG   
   LKQ/M1lwxLBc1zokReTgJpmqHJ00hNbDIgxUMxxAcrDI5qVXZEsbt1phlUpz67n4   
   EUgywqEu+3yJceq94KI+aEruZcal7wBznWPU7yw7xHBoAtRzcs5N452zkgcNfhBL   
   qYuBgnOVTqcqFZne0UhsoZ9d3lJKnhbkbKlKZB3CkpBVVsnVYLh9dwQoXv8cg3qR   
   XHNAsFDtzO7dKPyK5xUDK63F0RNqU1heKJadDkeWzD8jbNQ4DXtEyL8spyHl9c5y   
   EgHSGEVzglOJyMA2SEVjfxRWkmFlZcGA90eXEtLN4DlV9L2OX6qkFwrqPCaRkMDQ   
   Ndo1HlmLvSVOnCV+ISjcRJoorzgf2pFdjYKBBOzGqK7uesA4A6xrARGul1yUF1kU   
   Ealk4PyKCr5kMCqg4SW3itHYBw2IR0P8SWkHShPl79kzlKkAfgJfgQCIaZp+PRCe   
   vIuX3xS5PohDdqIR24Z1YZfz9CW24opn3/iy3Fqy8SboyUiDmMk=   
   =0IdV   
   -----END PGP SIGNATURE-----   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)