How to make a password for rm command?

Published on Author Code Father
How to make a password for ‘rm’ command? How to set up a password for ‘rm’ command?

This may not really be about the rm command, since there are easy ways to delete files without using it. If the problem is that your friends are unintentionally misusing the rm command, then solutions that restrict use of that command specifically or cause it to work in a different way may be of some help. In contrast, if the problem is that your friends are deliberately treating your data in a way you don’t want, then you need to implement actual security measures, and no solution that focuses on the rm command itself (or any discrete set of commands) will keep you safe.

Do you need to control access, or just prevent honest mistakes?

Assuming your friends know you don’t want them to delete your files, there are two possibilities:

  1. They could be doing it on purpose. In this scenario, your friends are deliberately deleting your files, and you cannot even trust them to try to comply with your wishes about how they treat your data when they use your computer. The only solution to this problem is to use an actual effective security measure, as Thomas Ward has explained in detail. Often the best such measure is to keep them from using your computer. But making them use their own user accounts can provide some protection.
  2. They could be doing it by mistake. In this scenario, your friends are extremely accident-prone, and they keep running rm commands they wish they hadn’t. They want to treat you and your data with respect, but are really bad at doing so in practice because they keep running the wrong command, deleting the wrong file… or something like that. Although it would be nice to believe that this is what’s happening, I caution you against assuming that people who keep deleting your data after you’ve told them to stop are operating without ill will.Furthermore, even if their intentions are good, giving them separate user accounts is still the most foolproof way of preventing them from deleting your files, aside from not allowing them to use your computer.

If the situation really is #2 — your friends are not trying to delete your files but just need help not accidentally deleting them, and the only way they ever accidentally delete them is through the inadvertent misuse of a small number of commands (like rm) that they have particular trouble using correctly — then the techniques in Videonauth’s answer may be of some use. But you must understand that they are not security measures, because the rm command is just one of many easy ways to delete files. See below for details.

I recommend you ask yourself, “Is my situation basically the same as if I, rather than the other people who use my computer, were the one using rm incorrectly?”

If the answer is no, then this is a matter of information security, and you need prevent your friends from using your user account. If the answer is yes, then you can use the same approaches you’d use if you were the one misusing rm:

  • Education. Your friends need to know what they’re doing and how to avoid it.
  • Interface changes. Without taking away the actual ability to delete files (which requires separate user accounts), you can make it harder to accidentally delete files by making it so just running rm file by itself, without any further action, won’t immediately delete file. Videonauth’s answer gives one approach to this. In this answer, I present another.

But even if your friends aren’t trying to do anything wrong, you should still consider having them use their own separate user accounts. This will still solve the problem — the same security measures that protect data from deliberate destruction will protect it from unintentional destruction, too. Even without malicious intent, if someone keeps doing something you don’t want them to do, then you cannot trust them to refrain from doing that thing.

Making rm prompt before deletion can help prevent some mistakes.

To help people avoid accidentally deleting files with rm, you can make rm a shell alias that actually runs rm -i. Passing the -i flag to rm causes it to prompt the user before deleting each file (see man rm).

You could do this (for your user account) by adding alias rm='rm -i' to your .bash_aliases or .bashrc file. See this question and that one for details. This will take effect for your newly opened bash shells.

This provides no actual security, and is not foolproof at preventing mistakes either, because:

  • They can choose to go ahead with the deletion, when prompted.
  • They can bypass the alias in numerous ways, including by running /bin/rm or unaliasing it (unalias rm).
  • There are many situations where alias expansion does not occur, and in these situations rm will not be run with -i.
  • They can still delete files by using any of the techniques to do so that do not require rm (as is the case with Videonauth’s approach — see below).
  • They can still damage data without deleting any files, such as by overwriting them or otherwise changing their contents (as is also the case with Videonauth’s approach).

But if you don’t need actual security (see above), then this might be the way to go. By comparison to the approach of preventing your friends from using the system-provided rm command:

  • Aliasing rm to rm -i is less effective at preventing mistakes — until they move on to using some other technique to remove files. At that point, keeping them from using rm will be entirely ineffective, even if they’re not trying to do anything wrong, since presumably they’ll use unlink(or any of the countless other commands that remove a file) with equal thoughtlessness.
  • On the other hand, because alias expansion only occurs in some situations — roughly speaking, ordinary interactive use of the shell — your friends might think they’re going to be prompted when they’re not really prompted (because the command is in a script, for instance, or issued from a different shell). Videonauth’s way does not have this problem, which is an objective advantage of that method over alias rm='rm -i'.
  • When a script runs, unless it is written deliberately to use aliases, your aliases are not expanded in it. This means that aliasing rm to rm -i is very unlikely to break anything. This is an objective advantage of alias rm='rm -i'.

rm can’t do anything any other perfectly ordinary program couldn’t do.

There’s really nothing special about rm. It is a convenient and self-documenting way to remove files, so restricting access to it risks breaking numerous scripts that rely on it. But it is far from the only way to delete files — it’s just an ordinary program.

A few commands perform some task that a limited (non-root) user cannot perform without running them. For example, sudo lets you run programs as another user, after checking to ensure you’re allowed to do so. passwd edits the database where users’ passwords are stored, but only lets you change your own password (unless you’re root, in which case you can change anybody’s password).

/usr/bin/sudo and /usr/bin/passwd can do that because they have the setuid bit set, as shown by the s that appears in the leftmost column when you run ls -l:

ek@Io:~$ type -a sudo passwd rm
sudo is /usr/bin/sudo
passwd is /usr/bin/passwd
rm is /bin/rm
ek@Io:~$ ls -l /usr/bin/sudo /usr/bin/passwd /bin/rm
-rwxr-xr-x 1 root root  60272 Feb 18  2016 /bin/rm
-rwsr-xr-x 1 root root  54256 Mar 29  2016 /usr/bin/passwd
-rwsr-xr-x 1 root root 136808 Aug 17 09:20 /usr/bin/sudo

Notice that /bin/rm has no s: its permissions are -rwxr-xr-x, while /usr/bin/passwd and /usr/bin/so have -rwsr-xr-x instead. This makes it so that, no matter who runs passwd or sudo, it actually runs as the root user, since root is the owner of the executable. (There is also a setgid bit, which, when set, causes executables to run with the group identity of their group owner rather than that of the caller.)

Except for any security vulnerabilities that haven’t been discovered yet (or that have been discovered but haven’t yet been patched), sudo and passwd are safe because those utilities are very carefully written so they can only do things that the caller ought to be allowed to do.

/bin/rm doesn’t work this way. It’s not setuid because it doesn’t need to be. Directory permissions (and occasionally file permissions) control what files a user can delete, and they don’t need to become root to do it. Just to be perfectly clear, please do not ever set the setuid bit on rm. The security implications would be disastrous, since then, no matter who runs rm, it’s as though root ran it! (Utilities like sudo and passwd check who’s really running them and check that something is permitted before doing it; rm does no such thing.)

Checking if the setuid (or setgid) bit is set on an executable will tell you if restricting who may run it stands a chance of improving security. Executables that aren’t setuid (or setgid) don’t have any special status, and anyone can simply copy them and run the copy, bring their own copy from another machine, write a script or program that does the same thing, or use another program to do it.

Deleting Files Without rm

The obvious way to delete a file without rm in Ubuntu is to navigate to its location in the graphical file browser (Nautilus, if you’re using Unity or GNOME Shell) and delete the file. There are also numerous commands that can be used to delete a file from a terminal, without ever using rm.

For example, to remove a file called foo.txt in the current directory, the following commands, which work out-of-the-box on Ubuntu and do not require access to rm, will achieve that. (Just to be sure, I tested them on a 16.04 minimal system installed with only the standard system utilities, after deleting /bin/rm.)

  • unlink foo.txt
  • busybox rm foo.txt
  • perl -e 'unlink("foo.txt")'
  • python3 -c 'import os; os.remove("foo.txt")' (python instead of python3 in older releases)

That list is, of course, nowhere near complete. No complete list of such commands is possible. Preventing file deletion is one of the things separate user accounts and file and directory permissions exist to achieve. They work very well to prevent it. In contrast, changing the rm command (to make it require a password, or in any other way) or restricting access to rm don’t prevent it at all.