Re: Please, don't let sudo be auto-removable
David Wright wrote:
> On Thu 31 Jul 2025 at 19:07:30 (+0000), Andy Smith wrote:
> > On Thu, Jul 31, 2025 at 08:01:56PM +0200, Jan Claeys wrote:
> >
> > We have learned in this thread that sudo does already have a check in its
> > prerm that prevents its removal if the system has a root account with no
> > password or if root is a locked account.
> >
>
> Do other flavours of linux and unix do this? I view this sort of
> protection in the same way as, for example, making "rm -i" the default
> behaviour of rm. It leads people to assume there's always a safety net
> when their actions are reckless.
It's not that there's a safety net, so much as multiple methods to
recover from most situations, with varying degrees of pain.
The su command goes back to AT&T UNIX. You'll find it in Linux, the BSDs,
OpenSolaris descendants and even minix. To use it, you need to know the
root password.
You can start a new console on the physical hardware and login as
root. Again, you need to know the root password.
If you can reboot, you can change the kernel command line in grub or
another bootloader and make your init be shell; then you need to remount
the root filesystem read/write, change root's password with passwd or
replace the hash in /etc/shadow, sync and reboot -- now you know the
root password. Once you have root, you can do anything at all to the
data that you have on the system. (There are exceptional circumstances
involving read-only media or contrived SELinux configurations.)
If you wipe out a filesystem with data on it, it may well be unrecoverable
-- unless you have already taken precautions, of which the most widely
known is making a backup. Depending on what happened and when, a snapshot
can save you. Physical loss of a disk? The right RAID setup (in advance)
can turn it into a mere inconvenience or slowdown.
If your data is corrupted, you may not notice until it is too late,
unless you are running a verification procedure. Regardless of whether
the corruption was malicious or accidental or caused by a fault, the
recovery procedure always involves identifying the corrupt data and
replacing it with a stored copy from elsewhere.
-dsr-
Reply to: