Hi Russ, On Thu, Aug 08, 2024 at 08:40:46AM -0700, Russ Allbery wrote: > Just to be sure, though, I don't think this is the problem that Thorsten > was worried about. My understanding of the problem Thorsten was reporting > was slightly different:
Thank you for bridging the gap in communication. > 1. A user has pointed /bin/sh to mksh, via a local diversion, changed > symlink, or whatever other mechanism. The current mksh package, which > from dpkg's perspective provides /bin/mksh, is installed. > > 2. A new version of mksh is uploaded that no longer provides /bin/mksh and > does provide /usr/bin/mksh. > > 3. dpkg unpacks and installs that package. This involves some sequence of > operations that, from dpkg's perspective, remove /bin/mksh and install > /usr/bin/mksh. However, these are both the same file. My > understanding of Thorsten's concern is that there may exist a window > during which dpkg would delete /bin/mksh, since it is no longer > included in the package, before it installs /usr/bin/mksh, and thus > there could be a window where /bin/sh is a broken symlink. If the > system crashes in that window, recovery could be annoying. Such concern is unwarranted. When dpkg unpacks a .deb, it unpacks all the files with a .dpkg-tmp suffix appended. Hence, we also get a file /usr/bin/mksh.dpkg-tmp. Once all of these are synced, it issues a sequence of renames, including rename(/usr/bin/mksh.dpkg-tmp, /usr/bin/mksh). This will atomically replace mksh even though it was formerly /bin/mksh (but the same file via aliasing). At no time will looking up /bin/mksh yield -ENOENT. If you want to verify this, you can do a very similar experiment by upgrading dash from bookworm to trixie and observing its behaviour about /usr/bin/dash using strace. mmdebstrap bookworm /dev/null --variant=apt --include=strace --customize-hook='sed -i -e s/bookworm/trixie/ "$1/etc/apt/sources.list"' --chrooted-customize-hook='apt-get update && apt-get -y install libc6 && apt-get download dash' --chrooted-customize-hook=bash In there, strace dpkg -i dash_*.deb. > I am unfortunately not very familiar with the ordering guarantees provided > by dpkg and with the precise mechanism of dh_movetouser. I did look over > the source of the latter and didn't see anything that obviously seemed to > handle this case, but I quite likely missed something. This presumably > has come up with other packages (libc6, for example), so maybe there's > something that makes this safe that I'm not aware of? dh_movetousr is rather boring as it runs at build time and just moves files inside the data.tar from / to /usr. You can often achieve the same effect by changing debian/*.install files and adding a couple of "usr/". I'm not sure how it would be relevant to ordering guarantees of dpkg. > Maybe the protective diversions also protect against this problem as well > as the problem of moved files? I unfortunately failed to spot where the > protective diversions were added in dh_movetouser (if that even is the > right place to be looking), so I'm fairly sure I'm missing something. dh_movetousr has nothing to do with protective diversions. It does not add nor remove diversions nor does it change any. All it changes is locations of files in the data.tar of a .deb. All of the protective diversions that we ever installed for DEP17 are managed in maintainer scripts and dh_movetousr does not touch maintainer scripts at all. > Do we document for users somewhere how to change /bin/sh, as a replacement > for the debconf questions? When I was investigating this, I tried to find > documentation in the bash and dash packages and was unsuccessful. That's > not a Policy question, of course, just an aside, but this sounds somewhat > complicated and I'm not sure a user would be able to figure out the new, > correct way to change /bin/sh. I also looked and could not locate such documentation. dash/0.5.11+git20210903+057cd650a4ed-8 mentions: | * Remove the remnants of the debconf shell question | (Closes: #1007093, #1007241). In the first bug, Andrew stated that selecting the shell via debconf wasn't supported. The submitter of the second indicates that the debconf choice didn't practically work. Earlier, dash/0.5.11+git20210903+057cd650a4ed-4 mentions: | * Stop using debconf to select the default /bin/sh. But no NEWS nor documentation seems to have been added at that time. I also had my hands in this. I sent the patch for removing the diversion of dash for itself (#989632). It was applied during the trixie cycle. This work enables us to have no diversion in the common case of /bin/sh pointing to dash. > It sounds like the plan is to cover this in the relesae notes, which is > great, but we probably also need ongoing documentation for the future. > I'm not sure the best place to put that. Maybe just in README.Debian for > whatever package currently provides /bin/sh by default. Your reasoning makes sense to me. I do not intend to work on this matter, because I am not interested in changing /bin/sh. Helmut
