Consider using /dev/disk/by-{path,id}/

/dev/disk/by-path/ has symlinks to block devices, where the names of the symlinks describe the "hardware path" of the device (subsystem, bus, controller, port, etc). A redacted listing on my system shows an nvme device, a sata device, and a USB drive (and the first partition on each):

/dev/disk/by-path ├── pci-0000:00:14.0-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sdc ├── pci-0000:00:14.0-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sdc1 ├── pci-0000:00:17.0-ata-2 -> ../../sda ├── pci-0000:00:17.0-ata-2-part1 -> ../../sda1 ├── pci-0000:02:00.0-nvme-1 -> ../../nvme0n1 └── pci-0000:02:00.0-nvme-1-part1 -> ../../nvme0n1p1 

/dev/disk/by-id works similarly, but has the subsystem, the device brand/model and serial number instead. I sure seem to have a lot of Samsung storage:

/dev/disk/by-id ├── ata-Samsung_SSD_860_EVO_500GB_XXXXXXXXXXXXXXX -> ../../sda ├── ata-Samsung_SSD_860_EVO_500GB_XXXXXXXXXXXXXXX-part1 -> ../../sda1 ├── nvme-Samsung_SSD_980_PRO_1TB_XXXXXXXXXXXXXXX -> ../../nvme0n1 ├── nvme-Samsung_SSD_980_PRO_1TB_XXXXXXXXXXXXXXX-part1 -> ../../nvme0n1p1 ├── usb-Samsung_Flash_Drive_FIT_XXXXXXXXXXXXXXXX-0:0 -> ../../sdc └── usb-Samsung_Flash_Drive_FIT_XXXXXXXXXXXXXXXX-0:0-part1 -> ../../sdc1 

Assuming your goal is to not confuse plugged in USB drives and your (sata/nvme) system drive, these names may be helpful. You can just these names for your commands, and that should work as expected:

fdisk /dev/disk/by-id/usb-Samsung_Flash_Drive_FIT_XXXXXXXXXXXXXXXX-0:0 mke2fs /dev/disk/by-id/usb-Samsung_Flash_Drive_FIT_XXXXXXXXXXXXXXXX-0:0-part1 

And hopefully this catches your eye enough to abort:

mke2fs /dev/disk/by-id/nvme-Samsung_SSD_980_PRO_1TB_XXXXXXXXXXXXXXX-part1 

A simple ruse is to rm /dev/sda /dev/sda1 and so on after booting, if you want to prevent accidental reference to these devices. You can always re-create the inodes with mknod /dev/sda1 b 8 1 and so on if needed, but umount /dev/sda1 works without this, as it presumably has the appropriate information somewhere.

But it is really a question of good hygiene; preferably don't login as root, nor su to root, or if you must do so in only one terminal with a red background colour, don't copy-paste into it, write scripts for repetitive tasks and make sure they check the parameters and do other sanity checks.

Well, there is blockdev --setro to make a block device read-only (--setrw for read-write).

# blockdev --setro /dev/sdx3 # mkfs.ext4 /dev/sdx3 mke2fs 1.47.0 (5-Feb-2023) /dev/sdx3 contains a vfat file system Proceed anyway? (y,N) y /dev/sdx3: Operation not permitted while setting up superblock # wipefs -a /dev/sdx3 wipefs: /dev/sdcx3: failed to erase vfat magic string at offset 0x00000052: Operation not permitted 

So can you make a block device read only even for root? Yes. Well, kind of.

However, it's not very reliable. For example, if the kernel re-reads partition table for any reason. Even if the partitions did not actually change, after a re-read /dev/sdx3 is technically a new device, which never had this ro flag set.

So at minimum you would need some udev rules that manage and maintain your readonly flags at all times. (If there is a flag anywhere that makes block devices readonly by default, I'm not aware of it.)

Also anything that is already using the device in write mode, may continue to do so. So this does not affect mounted filesystems ... until those filesystems try to re-open the device for any reason (when changing mount flags on re-mount or otherwise).

And of course making a partition readonly does not prevent something to write to the main device at an offset - or vice versa. It's normal to have multiple block devices pointing to the exact same storage area. You'd have to make sure to set all of them readonly, not just one.

So it's possible, yes, just not very practical to do.

Setting this flag might cause errors with other programs and such errors could lead just to a different kind of data loss. Normally you want writes to succeed or lose whatever was supposed to be written.

So it's entirely possible for this approach to cause more problems than it solves. In the end you still want to format your USB stick, for that you have to make it writeable, and for that you have to be able to identify and use the correct device name and not mix it up with a wrong name.

You can check under /dev/disk/by-*/* if there's a more suitable name, for example /dev/disk/by-id/usb-Flash… is unlikely to refer to an internal drive.

Not a real solution, but you could hide the dangerous commandos behind wrapping shell scripts that check the command line arguments for dangerous devices.

There might be also ways to use security systems like SELinux, AppArmor, ... to restrict access also for root.

You're looking for a technical solution to prevent you from doing something bad on your computer.

One way many of us learned to avoid these was by doing it wrong and then losing data. We learn to slow down and double-check things.

If you're able to learn from someone else's mistake, then that's great. I learn really well from my own mistakes.

A technical solution may work fine on your computer as it is now. Improving your approach to risky actions will help you on any computer in the future.

Unix is about small tools that do a small job well. Like sharp knifes and scissors and chisels, it’s all how you-the-user approach them.

Be comfortable with a tool, but never complacent.

to my surprise, chmod 0000 /dev/sdc1 followed by mkfs /dev/sdc1 works completely fine.

As root, yes, since root is exempt from the usual file permission bit checks...

Now, I would have suggested not running as root but fixing the device permissions (through udev, likely) so that you can run mkfs under your usual user account. But you have a point on needing e.g. mount too.

So, you need to be able to be root for mount, but not for mkfs.

One way would be to arrange to run a session where you have some but not all of the capabilities that the superuser special rules actually rely on (on Linux). You'd need e.g. CAP_SYS_ADMIN for (u)mount, but would not want to have CAP_DAC_OVERRIDE, which is the one allows bypassing permission checks. I'll leave the implementation "as an exercise", though. You'll want to see capabilities(7) and setcap(8), in the least.

Another possibility would be to run the commands needing admin rights through sudo, and set the rules in sudoers so that you can run mkfs /dev/sdc, but not mkfs /dev/sda. One way to do that would be to have sudo only allow you to run a wrapper script, which then does any necessary checks.

Like this one, which runs mkfs using all the arguments it was given, but not if any of them contains /dev/sda:

#!/bin/sh for arg in "$@"; do case $arg in /dev/sda*) echo "I don't think you should touch 'sda', exiting..." >&2; exit 1;; esac done mkfs "$@" 

Of course, those are basically sidestepping the question, but e.g. SELinux should be able to actually restrict root, if you care to go through the trouble of setting the policies accordingly.

To the best of my knowledge, you cannot do something to a system that root cannot undo unless you break something. Such a state would be considered an error condition, not a configuration.  You also have to account for the fact that you can destroy a partition table without formatting in the traditional sense, with something such as

dd if=/dev/zero of=/dev/sda bs=512 count=1 conv=notrunc 

There are devices, however, that you can set to read-only mode.  Examples of two:

• Kanguru USB Drives With A Physical Write Protect Switch

• Aegis Secure Key 3.0

Since that would be write protect at the hardware level, any attempts to overcome it, as any user with any rights, would still fail.  The ability to alter the drive's contents in any way at that phase would be conscious will, not mistakes.

If the intent is just to prevent mistakes, jofel's answer of scripts / aliases is a +1.  But, as pointed out, this can lead to very bad habits.

I like to enforce the best-practice of marcelm's answer by a bash trap. You can save this to a file and source it in your current session. If you like it, you can add it to your .bashrc. Since this works on the local shell, it also covers direct usages of sudo (though not sudo -i).

# disallow accessing block devices directly reject_devsdx () { # only check if being executed at the top-level (by the user, but not when doing tab completion) if [[ -z "${FUNCNAME[1]}" ]] then blockdev_path="" # check all the arguments for arg in ${BASH_COMMAND} do # it is safe to use ${arg} without quotes here since the for loop has split it anyway if [[ ${arg} =~ "/dev/" && "$(LC_ALL=C stat --format %F $(echo ${arg} | grep -oE /dev/[^\"\']+))" == "block special file" ]] then blockdev_path=${arg} fi done if [[ -n "${blockdev_path}" ]] then aliases="$(find /dev/disk -type l -printf '%p -> ' -exec readlink --canonicalize {} ';' | grep --word-regexp ${blockdev_path})" if [[ -n "${aliases}" ]] then echo "Stop being stupid. Use one of these:" echo "${aliases}" return 1 fi fi fi } shopt -s extdebug trap reject_devsdx DEBUG 

Inspired by ulidtko's answer. This question is about similar mechanics. Fancy hints courtesy of this answer.

Echo your commands before running them.

This won't prevent you doing anything, but it's a habit I developed for more or less the same reason as:

I fear that accidentally I may mistype one single letter, and format my hard drive.

When you're about to run a dangerous command, first, run

echo dangerous_command 

You can then check it's correct, press up, delete the word echo, and run it for real, knowing that the command itself is unchanged.

I find it particularly helpful for one-off loops with variable substitutions like

for a in ... ; do echo dangerous_command "$a" ; done 

to make sure it's not about to e.g. run on the completely wrong set of files, but it can work just as well for simple, literal commands too.

Caveat: naturally, this won't work as easily if you've got things like pipes, redirection, or multiple commands involved, though there's usually similar things that can be done there.

Some utilities have --dry-run arguments - for that matter, mkfs.ext4 for example has a -n argument - though this is less helpful, as commands don't have to implement such an argument, and might go ahead with dangerous actions even if an unknown argument is present.

Too short for an answer, really, but comments don't show code very well.

Don't you get a warning? Like this:

# mkfs -t ext4 /dev/sdg mke2fs 1.46.2 (28-Feb-2021) /dev/sdg contains a iso9660 file system labelled 'Debian 11.2.0 amd64 n' Proceed anyway? (y,N) N 

I often format different media, and it happens that I choose the wrong one - but the warning takes most, if not all, of the risk away.

You can remove and move the disc files that you want to protect. Add the following script to rc.local or other startup location:

mkdir -vp /dev/DO_NOT_TOUCH mv -v /dev/sda* /dev/DO_NOT_TOUCH 

That way you can still access them potentially with /dev/DO_NOT_TOUCH but it will be inaccessible under /dev/sda*.

I decided to also move all links from under /dev/disk with:

filter=(/dev/nvme*) mkdir -vp /dev/DO_NOT_TOUCH { printf "%s\n" "${filter[@]}" find /dev/disk -type l -exec readlink -nf {} ';' -exec printf "\t{}\n" ';' | grep -f <(printf "^%s\t\n" "${filter[@]}") | cut -f2 } | rsync -axui --progress --remove-source-files --files-from - / /dev/DO_NOT_TOUCH