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:
- 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.
- They could be doing it by mistake. In this scenario, your friends are extremely accident-prone, and they keep running
rmcommands 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
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
- 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 fileby 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.
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
You could do this (for your user account) by adding
alias rm='rm -i' to your
.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/rmor unaliasing it (
- There are many situations where alias expansion does not occur, and in these situations
rmwill not be run with
- 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 -iis less effective at preventing mistakes — until they move on to using some other technique to remove files. At that point, keeping them from using
rmwill 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 -iis 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/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
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
/bin/rm has no
s: its permissions are
-rwsr-xr-x instead. This makes it so that, no matter who runs
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),
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
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
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
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
busybox rm foo.txt
perl -e 'unlink("foo.txt")'
python3 -c 'import os; os.remove("foo.txt")'(
python3in 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.