sudo
First and foremost, beware of ANY code that includes the sudo or su commands that are used to run a program as a different user.
On Linux, by default a user can't modify, read, or delete files owned by other users. When you log into Linux, you log in as a user you created while installing the operating system. All the files in your home folder are owned by you (by your user). This means that if a program is run by your user, the worst it can do is delete all your files.
- Danger: Any Program Can Delete All Your Files
- What Read, Write, and Execute Permissions Mean on Linux
Note: if something you absolutely can't afford to lose was deleted, you may be able to recover it by turning off your computer immediately and contacting a data recovery specialist.
Linux systems also have a system-level user with full administrative access called root. Because this root user has access to the entire computer, it can literally delete the whole operating system. On top of that, this user is special in that it ALSO has access over files of other users, which means that besides deleting the operating system, it will ALSO delete all your files in your home folder.
To recapitulate:
- Any program can delete all your files, but the system will still boot, you can still log in, and the applications will still be installed.
- Any program running as
rootcan delete all your files AND delete the operating system, and then everything is gone forever.
At first glance, this looks like there isn't much difference, since your files will be gone either way. However, keep in mind that you do have the power to create other users to test things and run programs. For example, if you created a user called test, any program run as this test user can only delete files owned by test, which means that your files will be safe from any potential damage.
Naturally, it isn't realistic to expect people to create a separate user for every single terminal command they want to use, however, if you are learning how to use the terminal, creating a separate user to try terminal commands is a great idea as it limits the damage you can do to yourself. And believe me, it's very easy to type the wrong command in the terminal even if you know what the right command is.
sudo apt install
Normally, sudo apt install is a harmless command that just installs software on your PC. At least it can't be more harmful than the software it's going to install. apt, or Aptitude, is Debian's package manager, and there are similar managers in other distros, like Fedora's dnf. However, there is one unfortunate situation where sudo apt install can brick your operating system, and we have an extremely good example of this.
Yes, do as I say!
Linus Tech Tips [https://youtu.be/0506yDSgU7M?t=606] (accessed 2025-02-25)
When a package manager is told to install packages, sometimes there will be conflicting packages that can't both exist in the same system, which means that either you give up installing that package, or you replace the existing packages by compatible packages. Due to packages depending on other packages, which depend on other packages, resolving this can become complicated, since if you replace a package that all other packages depend upon, that means all those high-level packages must be removed as they no longer have the base package they require in order to function.
In this case, it's possible that installing one package requires removing an "essential package," which is a package that the distributor of the Linux distribution has configured as something that you really shouldn't uninstall unless you know what you're doing. This is often something that isn't just an application, but a critical part of the operating system, which may include the package manager itself, the default desktop environment (so you can't get yourself in a situation where you have no desktop environment installed), and things of sort.
In this case you may be asked for further confirmation, e.g. by being told to type Yes, do as I say!, and then if you type that, well, you can just watch the video linked above to see what happens.
Observation: it seems the Pop_OS! distribution Linus used just happened to be broken for a few weeks that coincidentally were when he downloaded the ISO image for the system, and that was the source of the dependency conflict when he was installing Steam. If he had updated the system before installing Steam, there probably wouldn't be a conflict. This is no excuse, however, since updating the system could have added a bug instead of removing one in an alternative universe, but it's worth noting that he was particularly unlucky that day.
chown, chgrp, chmod
The commands chown, chgrp, and chmod change the ownership, group, and permissions of a file or folder, respectively. These commands don't do immediate harm to your system, and there are many valid reasons to use them, but there are also ways to use them that increase risks of things going badly.
Sometimes, you may need to edit a root-owned file for some reason, and since you can't edit a file you do not own, one workaround is to change the ownership of the file to your user, and then you can edit it. Changing the group to your user also has the same effect.
The problem is that if you forget to change it back—and you'll forget to change it back—you can delete that file now when previously it would have been impossible.
On top of that, suppose that there is some file containing a program that the system runs on startup. This file is owned by root, so the system trusts that nothing but a system update can change the file. If we change the ownership, then any program we run as our user can change the program that will be run as root by the system, allowing them to run anything as root without needing sudo.
This may sound unlikely, after all, what are the odds a malware will try to infect just the one file we changed the ownership of that happens to allow them to gain elevated privileges on the system? That would be too lucky! But think as a hacker for a moment. If you're writing malware, you'll just try to edit every single file that's normally owned by root that can give you elevated privileges, and if any of them has had its ownership changed, you can take control over the system.
In most cases there is no reason at all to ever touch system files. I recall that in order to change the location of notification on Cinnamon (Linux Mint), one method was to edit root-owned CSS files, but that was in 2021, before they officially supported this feature. Now it's just a setting. If you do need to edit them for some reason, the recommended method is to use the terminal and a terminal-based text editor like nano or vi.
Long story short, was trying to give Plex permission to my home folder, I ended up just chmod 777 my entire / folder…
I rebooted my device, and noticed I can't use WiFi Went to do a update system through termind and I can't because sudo doesn't have permission anymore….
https://www.reddit.com/r/linuxmint/comments/1jaqffl/i_think_i_really_messed_up_my_machine/ (accessed 2025-03-15)
Malware that Runs in the Background
If an evil program isn't doing senseless damage to your computer, then it must be exploiting your computer for financial gain like some sort of parasite. There are many sorts of malware that can do this, and these are the same types that exist on Windows.
Malware typically "runs in the background," meaning that they display no graphical user interface, so you'll often be unaware that they are running. Programs that persistently run in this fashion are called "services" on Windows and daemons on Linux. If you have ever interacted with a program called systemd, that's a daemon that manages other daemons.
A program doesn't need root level access in order to daemonize itself. If the program can edit a user's configuration file to make itself start when you log in, and it simply never stops running, it's effectively a daemon, always running in the background. In this case, it would be possible to theoretically get rid of the daemon without knowing what program it is by simply creating a new user with a blank configuration and starting over. The configuration files are dotfiles (hidden files) in your home folder, so if you copied the entire home folder it would probably copy them as well, but copying only the non-dotfiles should get rid of this particular problem if it ever happens. If the malware has root level access, then things get a lot more complicated.
The Linux community is awfully complacent about desktop malware in general, as malware developers tend to target Windows, which has more users with less technical knowledge. Consequently, many Linux desktop installations have no anti-virus, with some claiming that Linux itself is their anti-virus.
However, just because things are like this today doesn't mean things will remain like this. It's possible that in the future we'll see more malware on Linux that targets individual users rather than company servers, and I'd rather not be one of their first victims.
If you have anything important on your computer that you can't afford to lose, it's always a good idea to make backups just in case the worst happens.
sudo rm -rf /
The command sudo rm -rf / will delete your entire filesystem. rm is the command to remove files. The -r flag removes files recursively, meaning you can pass a directory as an argument and then all files and subdirectories inside that directory will be gone. The -f flag means "force," which means confirmation won't be asked. / means the root directory—all directories descend from the root directory, so they will all be deleted.
The only silver lining about this command is that you will be asked for your root user password before it deletes everything, which means there is a chance you will reconsider it before destroying the system.
rm -rf ~/
The command rm -rf ~/ does the same thing as sudo rm -rf /, except it doesn't run as root, so it doesn't even ask for root user password, and it doesn't delete the entire system, "only" all the files in your home directory (represented by ~/).
echo `sudo rm -rf /`
GNU's bash is the default shell on many Linux distributions. Shell is the program that interprets your terminal commands. This means that the terminal command's syntax is bash's syntax in most distributions.
In bash, if a text argument has space characters, you must surround it by quotes, as the space character normally would separate one argument from the other.
cat "My Text File.txt"A backtick character (`), however, works in a completely different and unexpected way. The text surrounded by backticks is interpreted as a command. This means if you do this:
echo `whoami` `date`You don't get literally "whomai date" as output, you get the output of whoami command followed by the output of the date command. In other words, the text between backticks is being evaluated as shell commands.
Consequently, this will delete all your files:
echo `sudo rm -rf /`I've lost the link, but I've read that someone told others to run this command in the Linux Mint's subreddit.
echo $(sudo rm rf /)
Similar to the above, $(...) will execute the command inside, although this one is more obvious.
$FOO
It's worth noting that you can obfuscate what command you are running in many different ways if you are a malicious actor. Don't think for a moment that just because you don't see a rm -rf in the code it won't be executed.
For example, you can do this in bash:
FOO="sudo rm -rf /"
$FOOAnd then all your files are gone.
And if you can do this, that means you can also do something like:
FOO=`decrypt blahblahblah`
$FOOIn this example, we have some hypothetical command called decrypt, and the idea is that there is some argument we can pass to decrypt that will generate the text sudo rm -rf /. That is, the attacker encrypts the text in their PC using some method that is widely available on Linux (such as converting ASCII characters to their numeric equivalent), and then they use the reverse method in the victim's PC to get the command back.
You may look at all the commands and think it's just doing something you don't understand, when the code could be in fact trying to hide from you the commands that you do understand.
curl URL | bash
The command curl URL | bash or curl URL | sh will download a file located by a URL is execute it as a shell script, which is essentially the same thing as copy and pasting commands to run in the terminal without reading them, except it also has several other problems.
This is a bit controversial. Some developers claim the security issues of this practice are exaggerated, while some users claim they would never install something that tells them to just curl pipe bash some random URL.
The reason why developers prefer it is that it's a very convenient way to tell people how to install a software without having to deal with the fragmentation of distros. The problem is that this is really the only benefit of this practice. Everything else is downsides. In particular, there is no benefit for the user compared to other installation methods, except perhaps the indirect benefit of making the developer's life easier.
In other words, if a software can be installed via curl | bash and alternatively via a package manager, there is simply no reason at all to use curl | bash, as the package manager is always going to be the better option.
In ideal cases, if you know what you're doing, the developer knows what they are doing, and nothing extraordinarily bad happened, there is no problem with curl | bash, as it won't be much different from installing a program via a package manager. However, it's not a good idea to depend on this, for the following reasons:
1: Domain names can be hijacked, and servers can be compromised, which means that the file located by a given URL may have been tampered by a third party. Package managers are safe from this type of attack because they use cryptographic signatures to check if the downloaded file has been tampered with. It's worth noting that Github requires 2FA to publish code, so it's a bit harder for a malicious actor to compromise an account and change the code of an existing project. However, this isn't perfect. For example, you could phish a repository URL by forking it. If the URL isn't on the github.com domain, it's likely much less reliable. In essence, copy and pasting URLs is just not very secure at all.
2: If there is a problem downloading the script, curl will send an incomplete script to bash and bash will just execute it anyway. Although you can mitigate this by writing the script in a certain way, it's very likely some of the scripts you're told to download don't employ this sort of mitigation and could lead to installations just failing randomly after starting.
3: bash is a terrible programming language and I'd rather write 50 lines of Python using subprocess to execute shell commands than 10 lines of bash. It's very easy to make mistakes in bash, it's very hard to maintain bash scripts, and errors in bash can cause much greater damage than in other languages since it's very easy to rm things by accident. bash scripts tend to be small, until they become big, so developers may be complacent and skip writing unit tests for bash to have code coverage to prevent bugs that in real programming languages would be caught by static checks like forgetting you shouldn't add a space character before = when setting a variable, because foo = 3, foo =3, and foo=3 aren't the same thing in bash for some reason.
As you can see, using curl is a bad idea, and using bash is a terrible idea, so combining both of them has a good chance of going badly. The less curl | bash we have in our lives, the better.
And if you think you're good enough to write a bash install script that doesn't delete all your user's files, just remember that Valve did do the rm -rf /* in their Steam install script by accident that one time.
Moved ~/.local/share/steam. Ran steam. It deleted everything on system owned by user.
https://github.com/ValveSoftware/steam-for-linux/issues/3671#issuecomment-70159084 (accessed 2025-02-19)
rm -rf "$STEAMROOT/"*could be evaluated asrm -rf "/"*if$STEAMROOTis empty
Could this have happened with Python? It's certainly possible, but less likely.
For example, on Python, if a variable is undefined, you just get a NameError and the program stops there. In bash, it "$undefined/" evaluates to "/" unless you have used set -u before executing that. It's possible in the case above STEAMROOT was defined, but defined as an empty string, in which case Python's runtime type checks wouldn't have helped.
For counterarguments on why curl | bash isn't insecure, actually, see [https://sandstorm.io/news/2015-09-24-is-curl-bash-insecure-pgp-verified-install] (accessed 2025-02-19), a security startup whose pro-curl-pipe-bash arguments boiled down to "yeah things COULD go wrong, but WE are doing it right, so things won't go wrong with our curl-pipe-bashing install methods."
Running Graphical Applications as Root
In some cases, it may necessary to edit text-based configuration files that are owned by root. If you try to edit /etc/hosts, for example, you may notice that you can't save the file because you don't have write permissions on the file that you do not own. In this case, technically savvy but new Linux users often realize they can just use sudo gedit or sudo xed to open the text editor in administrator mode. Unfortunately, this doesn't work the way you expect.
When a program runs as a user, all files the program saves are saved as owned by that user by default, and normally they have no reason to think they should behave anyhow else. This is problematic for graphical applications because they tend to open configuration files in your home folder, and they save those configuration files when you exit the application, meaning that your configuration files will be "stolen" by root when you close the text editor. In that case, when you try to open the text editor again, it may not work simply because it can't open the configuration files you no longer own.
The root user has its own home folder, so you may be wondering why is root overwriting your configuration files when it has its own configuration files. That's because when you run things as another user with sudo, it only does the bare minimum to change users, and this means that environment variables are inherited from the current shell session, and among these variables there are some that tell graphical applications where the home folder is supposed to be.
If you need to edit files owned by root, it's a good idea to learn how nano or vi (Vim, NeoVim) work. They're terminal-based text editors, and I recommend nano because it's easier. I use NeoVim, by the way, to paste the code that I write in VS code because it's easier that way. Although terminal-based text editors could have the same problems, they're designed with the assumption you're going to use them to edit root-owned files, so there is no problem in calling sudo nano some-system-file.txt for example.
If you do accidentally run a graphical application as root and it messed the ownership of your configuration files, the only way to get it back is by calling sudo chown --recursive <your username> <your home directory>. Note that you need sudo in order to change who owns a file in the system.
Breaking Your GNOME Keyring
While I was trying to figure out [How to Run a Program as a Different User in Linux Mint], I discovered that there is an increasing number of settings you need to configure the more complex the application gets, specially to make the audio work, and to get the other user's keyring to unlock properly, which is necessary if you plan to use a web browser.
The "keyring" on GNOME, or "wallet" on KDE, is a system that stores user secrets like passwords. Web browsers make use of it because they come with a password manager now. The idea is that there is some password for the keyring that is used to encrypt and decrypt all the data stored in the keyring. If you lose this password you lose access to all the data in the keyring, which can be a pretty big deal depending on what you have stored there.
Normally, if you only have 1 keyring and that's your default keyring, it's automatically set to the same password you use to log into your account, and it's automatically unlocked when you log in, so you don't really need to deal with it until there is some bug and it stops working the way it should.
In my case, I managed to break my GNOME keyring by trying to unlock it via the terminal. Turns out if you call gnome-keyring-daemon --unlock the wrong way, it will overwrite the password with an unusable password, which to this day makes absolutely no sense to me, but it did happen to me twice. Fortunately, it was a test user, so no damage was done, but I just wanted to note that even I can type things into the terminal that I really shouldn't have typed in hindsight.
Nobody is safe from the dangers of the terminal.
This is why I prefer GUIs.
Observations
You must be this tall to rm rf: if you're really new to Linux, you may not even know HOW to copy and paste a command into the terminal because Ctrl+V won't work. I'd like to imagine that this may have saved someone some time!