XPost: linux.debian.policy   
   From: spwhitton@spwhitton.name   
      
   Russ Allbery [08/Feb 11:36am -08] wrote:   
   > 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.   
      
   Thanks for this.  Bind mounts are clearly better and have long been   
   supported, so I think it is okay to change this so long as we provide a   
   brief guide on using bind mounts for the same purpose in the release   
   notes.   
      
   > 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.   
      
   I think if the maintainers of the packages in which the change would be   
   effected are on board, we don't need to do that.   
      
   --    
   Sean Whitton   
      
   --=-=-Content-Type: application/pgp-signature; name="signature.asc"   
      
   -----BEGIN PGP SIGNATURE-----   
      
   iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmmYP4oZHHNwd2hpdHRv   
   bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQNQLEACloSJ/Eodz/vh1sUsIw4Cn   
   k+FYO6f55h3mkBP4XqQNuSCZbOSBYB3ZAUj1yFCGRzs1L5KSUfd0Y4DI2fwfKzYM   
   HsPP6XvrROeQvA0lNTRxxWlXjuka8wZMm7Zqx5ov6gqLESuDz6FhT39TcWFtPLQ/   
   jmWb7PEMuLvAmLwqgWs6PnFoyeN5TEYeKvSra2f5SrCtDjI6rHOVwQTFS/WAyQa0   
   9OxYxYvESEHSyNQHm+zYZoPHkYfvrKKN0vd8qrlvmjhHfit0YYbVdzBXELbRDJew   
   tttFsnNuwSz5bAuMVE4NqX6irsGEHK9InICgP5O08BY0FRWBG6xzkihAFK1DTp0D   
   o9UwaOdmWx+1deS0CfGbcdZFef/vn7ogx0J1feXgRCZjk+h4g07P/Ci2tD30qhLl   
   ICC6af5rMI4DkNL1NYmtxI0HBPI780gyJnOtmxSBfb6wx7/CTRL0TPE6t5je+Jre   
   akV+tyHAV29D9kvcHA3vFf9plvNOyvJdHVsL5Awpc+9rUPb7ijNZ7tL113RR8Ufc   
   HEibmARQ0UTikXtGyYi9D7ZM0GsEfT1OTEUJluWkMe9zA+EGw6k4XCoNPM2fZE6X   
   QdfaicoFYFx8U/GiDpHWuOzmF5Qj1uCAYQhrffhYQL0VJGob6acKGEIedxfl104H   
   dq9yyBs6EJj4sNxhU2LmVQ==dOKK   
   -----END PGP SIGNATURE-----   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)