Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
El 15/4/24 a las 22:26, Bill Allombert escribió: On Tue, Jan 30, 2024 at 09:52:39AM +, MOESSBAUER, Felix wrote: On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote: Package: base-files Version: 12.4+deb12u1 Followup-For: Bug #1039979 Control: tags -1 patch I attach a patch to change absolute symlinks to relative symlinks, which would fix this bugreport if you choose to do so. At least the /var/run directory is also created as a symlink to ../run by tmpfiles.d: /usr/lib/tmpfiles.d/var.conf from the systemd package contains: L /var/run - - - - ../run Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ? /usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is. Note that you are using here the words "fix" and "correct" to mean "what policy says". However, the point the reporter was trying to make (if I understood correctly) is that there is already a "trend" by which it's more useful to have those symlinks as relative, and the systemd reference was just to highlight such trend. So the question would be: Is policy really correct by requesting those symlinks to be absolute considering that there seems to be a significant amount of people (including systemd upstream) who consider more useful for them to be relative? Thanks.
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
On Tue, Jan 30, 2024 at 09:52:39AM +, MOESSBAUER, Felix wrote: > On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote: > > Package: base-files > > Version: 12.4+deb12u1 > > Followup-For: Bug #1039979 > > Control: tags -1 patch > > > > I attach a patch to change absolute symlinks to relative symlinks, > which would fix this bugreport if you choose to do so. > > At least the /var/run directory is also created as a symlink to ../run > by tmpfiles.d: > > /usr/lib/tmpfiles.d/var.conf from the systemd package contains: > L /var/run - - - - ../run Why not fix /usr/lib/tmpfiles.d/var.conf to create the correct link then ? /usr/lib/tmpfiles.d/var.conf is not policy-compliant as it is. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
reassign 1039979 debian-policy thanks Dear Policy editors: In this bug I'm asked to make /var/run and /var/lock symlinks to be relative. Maybe it's the right thing to do, but last time I tried to do that, this is what happened: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690345 [ Summary: I had to revert the change because it was against policy ]. So, I'm reassigning this bug to debian-policy. Please drop me a note whenever there is a consensus that relative symlinks are ok for /var/run and /var/lock (even if there is not a new policy release reflecting it yet). Thanks.
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
On Fri, 04 Aug 2023 10:44:38 + sohe4b+2fz7rb0ixc53g@cs.email wrote: > Package: base-files > Version: 12.4+deb12u1 > Followup-For: Bug #1039979 > Control: tags -1 patch > > I attach a patch to change absolute symlinks to relative symlinks, which would fix this bugreport if you choose to do so. At least the /var/run directory is also created as a symlink to ../run by tmpfiles.d: /usr/lib/tmpfiles.d/var.conf from the systemd package contains: L /var/run - - - - ../run There is also a proposal to update the debian policies regarding the directory structure below /var: https://lists.debian.org/debian-policy/2023/06/msg00016.html Especially for read-only rootfs images with a dedicated (unpopulated) /var partition, a solution using tmpfiles.d would be much appreciated. But it is tricky to find out what is still missing as these directories often get created in the postinstall scripts. Best regards, Felix Moessbauer -- Siemens AG, Technology Linux Expert Center
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
Package: base-files Version: 12.4+deb12u1 Followup-For: Bug #1039979 Control: tags -1 patch I attach a patch to change absolute symlinks to relative symlinks, which would fix this bugreport if you choose to do so. >From d08818adfe64f768fb31da1a3b095ff30bd3105a Mon Sep 17 00:00:00 2001 From: Your Name Date: Fri, 4 Aug 2023 10:40:28 + Subject: [PATCH] use relative links --- debian/postinst.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/debian/postinst.in b/debian/postinst.in index 0ad4ce3..dc00e49 100644 --- a/debian/postinst.in +++ b/debian/postinst.in @@ -74,8 +74,8 @@ if [ "$1" = "configure" ] && [ "$2" = "" ]; then ln -s ../mail "$DPKG_ROOT/var/spool/mail" fi install_directory run/lock 1777 root - migrate_directory /var/run /run - migrate_directory /var/lock /run/lock + migrate_directory /var/run ../run + migrate_directory /var/lock ../run/lock install_local_dir /usr/local install_local_dir /usr/local/share -- 2.39.2
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
Package: base-files Version: 12.4 Followup-For: Bug #1039979 PS: making /var/run and /var/lock relative symlinks makes it much nicer and safer to work with chroots, avoiding the risk of damaging the real system's /run It's also what archlinux does.
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
Package: base-files Version: 12.4 Followup-For: Bug #1039979 Debian policy "9.1.1. File System Structure" https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure states: "8. /var/run is required to be a symbolic link to /run, and /var/lock is required to be a symbolic link to /run/lock." Additional clarification is provided in https://www.debian.org/doc/debian-policy/ch-files.html#id24 "This is necessary to allow top-level directories to be symlinks. If linking /var/run to /run were done with the relative symbolic link ../run, but /var were a symbolic link to /srv/disk1, the symbolic link would point to /srv/run rather than the intended target." That part of the policy is certainly out of date with modern practices, where bind mounts and other solutions are commonplace and provide a much better solution to the described problem. For this bugreport to be fixed, it would require changing those parts of debian policy. However, the question is whether this is something against the letter of the policy but not against the spirit of the policy. My interpretation of the policy is that /var/run should end up pointing at the location of /run and it would be satisfied through relative symlinks too. Same for /var/lock
Bug#1039979: base-files: /var/run and /var/lock should not be absolute symlinks
Package: base-files Version: 12.4 Severity: normal Dear Maintainer, /var/run is currently an absolute symlink to /run /var/run should be a relative symlink to ../run if /var/run is deleted, then /usr/lib/tmpfiles.d/var.conf recreates /var/run as relative symlink to ../run /var/lock is currently an absolute symlink to /run/lock /var/lock should be a relative symlink to ../run/lock if /var/lock is deleted, then /usr/lib/tmpfiles.d/legacy.conf recreates /var/lock as a relative symlink to ../run/lock Both of these symlinks are currently created in base-files postinst. This is a problem because base-files currently deviates from the configuration files provided by debian in /usr/lib/tmpfiles.d/ Please fix. -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages base-files depends on: ii mawk [awk] 1.3.4.20200120-3.1 base-files recommends no packages. base-files suggests no packages. -- no debconf information
