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

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
> 
> 
>

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEXQGHuUCiRbrXsPVqADoaLapBCF8FAmmJpvYACgkQADoaLapB
CF+iCA/9GiyRjuMkBb+tEATYykdV0GI4O/cu8t5QVHpC2sK3PxVm+tikld+zawhf
t/8zvWvyjjU6lP1Mibf965ckGHW6HDK2cPuq/EL6x1NqvxM4qn9Nx4Djq7r+nudC
a1XgXBM8E7cpb1duE/qQgwtC9z7WSsiVojoIFwacHgF+p3DTbC4hMk2ogq+lfwRc
IhgOGJJ9LlMqwGrTrt9tFJ5JbDex10YlF5XPmSjWGZSIUdfHNy/jdx5sU4Ur558H
xnILuMoxOC6PURhDn0MFnRmVMN4Uy+JoUonL2plDYoZDyY36G1JWOoS3YPyzlDyW
SPG0HvHcenLiv5P52MxuuSsNluBndEx2ghbennK1K83HrhQ/2UhKAMw3sfBbRwdv
6vvJSTmhqcZfCADupRK1MKRjvH00t9ZDbhFWkm8yKwwGOUM1QrsBkDjKhqFoiWB3
FPxmd8E6ZHUML5f45oSP7QIODKODUbVsQT2C+zQ4wWaiDw/dRZ8tMKXTNctjnO6t
F966LsjDtuwra6AJ1ZEuvDUGE+QADi+BOVlv2uO1U4bD/6eEIjrWsZWuaG69YCDV
fY5dKvcL8QqDWsNt443KHz1RO/vhGpRzUdDYpME1vTRNuUFI1BqYm0+1nGsIXMGo
yb2iiU+G/mkYRu/HJo4USK4adFPajZh5HF81W1eG+H+KmZ8cxHU=
=DPCy
-----END PGP SIGNATURE-----