Bug#1039979: /var/run and /var/lock should not be absolute symlinks

Bastien Roucaries <[email protected]> Mon, 09 Feb 2026 10:18:37 +0100
Newsgroups	gmane.linux.debian.devel.policy
Message-ID	<4545485.G96rZvMJ2N__31429.6862970636$1770628893$gmane$org@debian-ei>
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 (application/pgp-signature, 833 B)