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

Sean Whitton <[email protected]> Fri, 20 Feb 2026 11:03:38 +0000
Newsgroups	gmane.linux.debian.devel.policy
Message-ID	<87jyw765it.fsf__3404.24257317267$1771585533$gmane$org@zephyr.silentflame.com>
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
signature.asc (application/pgp-signature, 869 B)