Hi!

While analyzing the archive for mismatched file metadata (as part of
the preparation to add support into dpkg), thanks to Helmut gathering
the data from the archive. I noticed that this package has a mismatch
in the permissions for the /var/lock/ directory compared to the
canonical permissions from base-files. The permissions of a directory
are decided by the first package being unpacked, and subsequent
directory unpacks get currently ignored (including any change in
permissions).

  $ dpkg-deb -c base-files_13.5_amd64.deb | grep var/lock
  drwxrwxrwt root/root         0 2024-08-04 23:30 ./var/lock/
  $ dpkg-deb -c drbd-utils_9.22.0-1.1_amd64.deb | grep var/lock
  drwxr-xr-x root/root         0 2024-07-17 19:22 ./var/lock/

While in this case, it currently poses no problem as base-files is in
theory always to be installed first (assuming one does not do funny
stuff with a bootstrapping tool). This mismatch might become a problem
in the future once dpkg grows filesystem metadata tracking, and this
kind of condition becomes either a warning or an error, which could
make this package uninstallable.

In this case I think the best option is to simply stop shipping the
/var/lock directory.

Thanks,
Guillem

Control: clone -1 -2
Control: retitle -2 base-files: is /var/lock a directory or a symlink?
Control: severity -2 normal
Control: reassign -2 base-files

This hints at another problem. Whilst base-files' data.tar lists
/var/lock as a directory, its postinst turns it into a symbolic link
pointing at /run/lock. If dpkg were to verify that /var/lock indeed is a
directory it would also issue a warning or error. I think this
inconsistency within base-files should also be solved in addition to the
one in drbd-utils.

Helmut

(Adding Chris to Cc as he was involved in the usr-merge change
that happened in base-files 13.3).

Sorry for the late reply.

I agree that this is an inconsistency and that we should try to fix it,
but I don't really know how much risky the solution will be.

The attached patch seems to work for me, I tested it by doing this:

dpkg -i base-files_14.0_amd64.deb

and nothing bad seems to happen. After the new base-files is installed,
both /var/lock and /var/run are symlinks, while they still belong to
base-files, and the postinst does not do any dirty trick anymore.

I have not tested if debootstrap handles this ok or not.
(can anybody help me to test that?)

And I also don't know if it's ok to do this change in base-files
before we fix drbd-utils, or maybe we should fix drbd-utils first.

If we make /var/lock to be a symlink which belongs to base-files and
drbd-utils is fixed later so that it does not contain /var/lock
anymore, what will happen with /var/lock?

(Maybe the fact that those symlinks are still part of base-files
is what will allow drbd-utils to drop the directory without
creating a mess)

[ Note: I also plan to make those symlinks relative once that Debian
  Policy editors allow me to do so, and maybe I will do that in the
  same upload, but that's a completely orthogonal thing so I'm
  ignoring that for the purposes of discussing this bug ]

Thanks.

Hi Santiago,

The safety aspect is difficult to judge. Maybe Guillem knows more here.

Generally, I would assume that dpkg could legitimately remove /var/lock
(as it might think it was a directory) and later recreate it as a
directory (making it temporarily unavailable). That could plausibly
cause a small window where /var/lock could be unavailable. Maybe that's
not what dpkg does today, but I would not consider such semantics a bug
in dpkg given the apparent type change.

Bootstrapping should just work as the location becomes unpacked by dpkg.

The other piece that might be affected is downgrades of base-files.

From my pov, the safe play would be adding protective diversions as we
did for /usr-move:

 * In the new base-files.preinst, create a protective diversion on
   scheduled upgrades crossing the relevant version boundary.
 * In the new base-files.postinst, always remove the diversion (so it
   does not stay around).
 * In the new base-files.prerm, create a protective diversion when
   "upgrading" to an old version crossing the relevant version boundary.

Note that the diverting package must be neither base-files nor
drbd-utils since we want the diversion to affect both of them.

Thus the diversion would be created before upgrading (or downgrading)
and removed when /var/lock is a symlink in the dpkg database. After a
downgrade, the diversion would remain permanently (until upgrading
again). Thus all dpkg operations would be diverted away from the symlink
until the on-disk state is reconciled with reality at which point dpkg
should be happy.

Since the ownership of the location remains with base-files, drbd-utils
should be fixed first. It does not need to depend on a fixed base-files,
but base-files should likely express conflicts with old drbd-utils
before it removes the protective diversion.

Chances are "nothing bad", because from a drbd-utils point of view
/var/lock is a shared file (with base-files) and since there are other
references, it will not be touched. However given metadata tracking in
dpkg, I would not want to rely on this and rather block the base-files
fix on drbd-utils being fixed first.

Helmut