[? maybe not but it left me with one dead box, so I'm inclined to inflate right now, downgrade if you want...] I just upgraded a hideous potato/sid hybrid box to woody; it use to have sudo 1.6.3p7-2 on it and when I installed 1.6.6-1.1 sudo broke complaining about a syntax error in /etc/sudoers. This screwed me quite nicely since I had neither an open root shell nor the root password. I think it'd be really nice if sudo would validate /etc/sudoers on upgrade and if it finds syntax errors abort the upgrade (or at least offer to). [Doing this would be interesting, you'd probably have to save a copy of the old sudo binary in the preinst, check with the new binary in the postinst and then restore it, if the new sudo can't validate sudoers, in the postinst - but given the alternative, I think it's worth it.]
notforwarded #192522 thanks # this is not an upstream issue This is indeed a completly ugly situation, potentially leaving a user without working root access if the root account doesn't have a password assigned. I am not sure where in poliy it is written, but I pretty well believe that a package is not supposed to meddle around with files in /usr, this being dpkg's domain. dpkg -D12 has still been a great help in finding the following things that I am recording here so that they are not forgotten. When dpkg unpacks a package during upgrade, there is a moment when the new binary is already there (as filename.dpkg-something) at the side of the untouched old binary. In this phase, the prerm script of the OLD package is run, so we could theoretically call the new binary and find out whether it is ready to eat the new configuration file. I expect that a non-zero exit code might probably cause dpkg to abort and roll back the package installation. I haven't actually tried this. The disadvantage of this approach is that an adapted prerm script would be useless in the first update round of the package since dpkg calls the OLD package's prerm during upgrade which doesn't have the new code yet. The protection of this code would not be useful until the SECOND round of upgrades. In addition, this "extra round" of package updates would also be needed for bug fixes in the code and such an round cannot even be forced here. Also, this feels like wading knee deep inside dpkg internals. I am therefore reluctant to implement this at the moment. Maybe this text can motivate somebody else to take a look at this after the bullseye release. I might do that myself because it's an interesting topic, but I wouldn't suggest that anybody hold their breath waiting for me. Maybe it would also be a valid approach to check whether sudo will accept the current configuration and if not, display a big fat warning and replace the configuration with the package's default. This might grant people from the sudo group more privileges as intended, but that might be better to do it this way than having the user end up with an inaccessible root account. A new sudo choking on an old, custom-made configuration is an unfortunate situation, but since this bug report is almost 20 years old and still hasn't accumulated any horror stories of people locking theirselves out, it's seldom enough to let this issue rest another bit. Not being able to properly roll back after a failed upgrade is a dpkg/Debian shortcoming in the first place. Greetings Marc
notforwarded #192522 thanks # this is not an upstream issue This is indeed a completly ugly situation, potentially leaving a user without working root access if the root account doesn't have a password assigned. I am not sure where in poliy it is written, but I pretty well believe that a package is not supposed to meddle around with files in /usr, this being dpkg's domain. dpkg -D12 has still been a great help in finding the following things that I am recording here so that they are not forgotten. When dpkg unpacks a package during upgrade, there is a moment when the new binary is already there (as filename.dpkg-something) at the side of the untouched old binary. In this phase, the prerm script of the OLD package is run, so we could theoretically call the new binary and find out whether it is ready to eat the new configuration file. I expect that a non-zero exit code might probably cause dpkg to abort and roll back the package installation. I haven't actually tried this. The disadvantage of this approach is that an adapted prerm script would be useless in the first update round of the package since dpkg calls the OLD package's prerm during upgrade which doesn't have the new code yet. The protection of this code would not be useful until the SECOND round of upgrades. In addition, this "extra round" of package updates would also be needed for bug fixes in the code and such an round cannot even be forced here. Also, this feels like wading knee deep inside dpkg internals. I am therefore reluctant to implement this at the moment. Maybe this text can motivate somebody else to take a look at this after the bullseye release. I might do that myself because it's an interesting topic, but I wouldn't suggest that anybody hold their breath waiting for me. Maybe it would also be a valid approach to check whether sudo will accept the current configuration and if not, display a big fat warning and replace the configuration with the package's default. This might grant people from the sudo group more privileges as intended, but that might be better to do it this way than having the user end up with an inaccessible root account. A new sudo choking on an old, custom-made configuration is an unfortunate situation, but since this bug report is almost 20 years old and still hasn't accumulated any horror stories of people locking theirselves out, it's seldom enough to let this issue rest another bit. Not being able to properly roll back after a failed upgrade is a dpkg/Debian shortcoming in the first place. Greetings Marc
notforwarded #192522 thanks # this is not an upstream issue This is indeed a completly ugly situation, potentially leaving a user without working root access if the root account doesn't have a password assigned. I am not sure where in poliy it is written, but I pretty well believe that a package is not supposed to meddle around with files in /usr, this being dpkg's domain. dpkg -D12 has still been a great help in finding the following things that I am recording here so that they are not forgotten. When dpkg unpacks a package during upgrade, there is a moment when the new binary is already there (as filename.dpkg-something) at the side of the untouched old binary. In this phase, the prerm script of the OLD package is run, so we could theoretically call the new binary and find out whether it is ready to eat the new configuration file. I expect that a non-zero exit code might probably cause dpkg to abort and roll back the package installation. I haven't actually tried this. The disadvantage of this approach is that an adapted prerm script would be useless in the first update round of the package since dpkg calls the OLD package's prerm during upgrade which doesn't have the new code yet. The protection of this code would not be useful until the SECOND round of upgrades. In addition, this "extra round" of package updates would also be needed for bug fixes in the code and such an round cannot even be forced here. Also, this feels like wading knee deep inside dpkg internals. I am therefore reluctant to implement this at the moment. Maybe this text can motivate somebody else to take a look at this after the bullseye release. I might do that myself because it's an interesting topic, but I wouldn't suggest that anybody hold their breath waiting for me. Maybe it would also be a valid approach to check whether sudo will accept the current configuration and if not, display a big fat warning and replace the configuration with the package's default. This might grant people from the sudo group more privileges as intended, but that might be better to do it this way than having the user end up with an inaccessible root account. A new sudo choking on an old, custom-made configuration is an unfortunate situation, but since this bug report is almost 20 years old and still hasn't accumulated any horror stories of people locking theirselves out, it's seldom enough to let this issue rest another bit. Not being able to properly roll back after a failed upgrade is a dpkg/Debian shortcoming in the first place. Greetings Marc
Marc Haber <mh+debian-packages@zugschlus.de> writes: FYI, I never found an acceptable solution to this problem, and chose to leave the bug open to remind myself and anyone searching for help that this *could* happen. It might be better to move this into a README.Debian clause or something and close the bug with no further action taken? Bdale
Marc Haber <mh+debian-packages@zugschlus.de> writes: FYI, I never found an acceptable solution to this problem, and chose to leave the bug open to remind myself and anyone searching for help that this *could* happen. It might be better to move this into a README.Debian clause or something and close the bug with no further action taken? Bdale
Marc Haber <mh+debian-packages@zugschlus.de> writes: FYI, I never found an acceptable solution to this problem, and chose to leave the bug open to remind myself and anyone searching for help that this *could* happen. It might be better to move this into a README.Debian clause or something and close the bug with no further action taken? Bdale
tags #192522
thanks
I had also instrumented the maintainer scripts like this:
{
printf "\n\n==========================================================\n\n"
date +"%Y-%m-%d %H:%M:%S-%N"
echo "instrumentation of postinst: $@"
ls -al /usr/bin/sudo*
sha256sum /usr/bin/sudo*
find /etc -name 'sudoers*' -type f | xargs head -n-0
visudo -c
} >> /tmp/sudo-postinst.log
to find out what was going on during the package upgrade process.
Greetings
Marc