Re: Please, don't let sudo be auto-removable
On 31/07/2025 02:41, Andy Smith wrote:
On Wed, Jul 30, 2025 at 07:55:12PM +0100, Darac Marjal wrote:
There's an argument that sudo should refuse to uninstall itself (e.g. in a
prerm script) if the root user doesn't have a password at all. That would be
a neat trick.
That's an interesting idea. sudo pre-rm could say, "please set a root
password and retry" or something. I took from OP saying about "who
remembers root password?" that they did have a root password set though,
in which case this wouldn't help of course.
Just a data point. I use pre-built images in LXC containers (the
"download" template). I do not need sudo there since lxc-attach is
enough for me. After a recent security fix in sudo I decided that I can
remove it instead of upgrading. Initial attempt failed:
apt purge sudo
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
sudo*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 6199 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 13241 files and directories currently installed.)
Removing sudo (1.9.13p3-1+deb12u1) ...
You have asked that the sudo package be removed,
but no root password has been set.
Without sudo, you may not be able to gain administrative privileges.
If you would prefer to access the root account with su(1)
or by logging in directly,
you must set a root password with "sudo passwd".
If you have arranged other means to access the root account,
and you are sure this is what you want,
you may bypass this check by setting an environment variable
(export SUDO_FORCE_REMOVE=yes).
Refusing to remove sudo.
dpkg: error processing package sudo (--remove):
installed sudo package pre-removal script subprocess returned error
exit status 1
dpkg: too many errors, stopping
Errors were encountered while processing:
sudo
Processing was halted because there were too many errors.
E: Sub-process /usr/bin/dpkg returned an error code (1)
I am not motivated enough to test various install scenarios to reproduce
it. At least 1.9.13p3-1+deb12u1 had enough protection in my opinion.
The questions to the topic starter is which way Debian was installed.
Cloud images may have their own specifics. Marking sudo as manually
installed by default might be reasonable for some approaches to install,
but it does not look like responsibility of sudo maintainers.
Reply to: