Always do rm -rf "${var:?}/" so that the script aborts if the variable is empty. Or better yet rm -rf "./${var:?}/".
Edited to add quotes. Always quote a path: it might have spaces in it, without quotes that will become multiple paths! Which would also have avoided the particular bug in question.
Is there not also a way to disallow empty variables in the script, I think it is set -u? Then you don't have to keep thinking "should I add a :? here because if empty it may lead to disaster" all the time. Might be even safer.
set -euo pipefail at the top of every script makes stuff a lot safer. Explanation here.
Yep! I always do this too.
TL;DR: e aborts the whole script on a non-zero error. u aborts when using an undefined variable. -o pipefail aborts a piped compound command when one of the piped commands fail.
Any other way lies madness. Or erasing the whole filesystem apparently!
Yes! But -u is for undefined variables. It won't stop a defined variable with an empty value. E.g foo="".
Also ? and :? have the advantage of telling you right then and there where the variable use is that it must be defined or not empty... having to trek back to (likely) the top of the script to check is easily forgotten.
Reminds me of a script a colleague has where it would sometimes accidentally wipe the entire production folder on a server. I pointed out the risk in his script and explained how to correct it like 2 years ago, give or take. He said he did, but then last week it happened again because apparently he had several scripts like that and only corrected one.
You can lead a horse to water, but you can't force it to drink.
In this case the issue was that a change between kde5 and kde6 let to the variable being defined as somepath / (notice the space).
And that's why you also surround it with double quotes.
I usually have a whole block that checks if the var exists and exits if not, but this is way more elegant
Protects you from accidentally changing the variable within the block too!
An extra space at line 351:
rm -rf /usr /lib/nvidia-current/xorg/xorg
Yikes
That reminds me...
In circa 1995 I was running a dial upBBS service -- as a teenager. So if course, it was full of bootlegged video games and such, and people would dial in, download a game, log off.
Someone uploaded Descent or something like that. But they had put "deltree /y C:" or similar into a batch file, used a BAT2COM converter program, then a COM2EXE program, then padded the file size to approximately the right size with random crap (probably just using APPEND)... And uploaded it. Well, fortunately for the rest of my users, I say the game and said: oh, that's neat, I should try it and copied it to another computer over my internal network and launched it. It started deleting files right away and I hit CTRL-C to abort. I lost only a few dozen files.
Banned the user, deleted the package. Got lucky.
The theme contained rm -rf, but claims it wasn't malicious intent...I assume rm -rf for cleanup, but seems like it should have a apecific path other than /
The command was rm -rf $pathvariable
Bug in the code caused the path to be root. Wasn't explicitly malicious
Don't most distros have safeguards against this? I tried sudo rm -rf / in an Ubuntu VM that I was about to delete just to see what happened, and it gave me a warning. I had to add some other option to bypass the warning.
it apparently was defaulting to the home dir, not /
Oh, oof.
Hopefully most people take regular snapshots.
Yes,
rm -rf --allow-unsafe
Or something is required
--no-preserve-root
When I worked at Pixar long ago an intern had a cron job that was intended to clean up his nightly build and ended up deleting everything on the network share for everyone!
Fortunately there were back-ups and it was fine, but that day was really hilariously annoying while they tracked down things disappearing.
Was that the infamous Toy Story 2 incident?
Amusingly enough, no.
This was after Toy Story 3 released but before Brave.
Oof
Was it a native theme or a downloaded/custom theme?
Downloaded from the KDE store
Thank you. I couldn’t get google translate to work for me.
Custom download
A Linux user's nightmare: the machine was wiped clean with one click
Timo Tamminen
One day a Linux user using KDE Plasma decided to download a generic theme for his desktop environment. This is possible with Plasma's built-in tool, through which you can download anything from themes to icons and wallpapers.
Installing themes using Plasma's tool is easy and fast. It practically only requires one click. This time, however, the user in question certainly wishes that that one click had not been completed.
Namely, installing the theme called Gray Layout wiped the machine completely empty of the user's personal files. Without asking anything.
Although the theme developer's intention this time was apparently not malicious, the accident was a clear indication that installing third-party themes without careful supervision can be a bad mistake. With the theme, almost anything can be installed in the user's home directory.
The Gray Layout installation script ran the rm -rf command, which normally removes all files from the device, making the command particularly dangerous to use. However, without root access, it can only cause limited damage.
Reddit user Jeansen Vaars says that he lost all his games, settings files, browser history and other contents of his home directory in a crash.
The unofficial face of KDE, Nate Graham, apologizes for what happened. He promises that the matter will be thoroughly investigated. The theme in question has also been removed from the theme store.
A theme is software and software has bugs. While this one had a pretty dramatic effect, you take basically the same risk with every program you run. This, along with hardware and user errors are why backups are so important; they change a disaster to an inconvenience.
/ Preach mode off
A theme is software and software has bugs
I honestly did not know that KDE themes contained executable code. When I think "theme", I think of cosmetic settings that plug into an existing program, which I would hope sanitizes its input and does NOT execute arbitrary code. I don't think "arbitrary executable code running as root".
I'm assuming KDE warns you about this when you try to install a theme, right? I'm not at my KDE system to test at the moment. I did try downloading a theme tar from the web site, and it doesn't seem to contain any code — just SVG files, a colors config file, and a metadata file.
It may help to know a bit of history: KDE3 themes could include a bespoke widget style, and QT3 widget styles were always implemented as executables (you can look at modified versions of the C++ code in the TDE git repository, if you're really bored). So keeping code out of the themes hasn't been important to KDE for at least the past 20 years. If I'm not mistaken, far more things are stylable in current versions of KDE. That doesn't mean that every theme will style all of them, though—you can have codeless styles like the one you found, that make use of the built-ins rather than trying to change All The Things.
Breeze, for example, contains a lot of code. For instance
A windows device just wiped the hardware settings of a periphery device, because it got an update and the new lighting settings wanted to control the LEDs in that device. All gone
The Gray Layout installation script ran the rm -rf command, which normally removes all files from the device
Translation difficulties, or does the author really think that's what it's normally used for?
It's an accurate translation. Mikrobitti is a generic computer magazine (with a long history) so it could either be that the author is not very familiar with Linux cli or it might also be that they were trying to put it in layman's terms.
That's what good backups are for.
I image all my PCs daily with Veeam, bootable media is on my Ventoy USB stick, and restoring is easy as you just boot up the restore media and it pulls the latest backup over the network.
Click bait
I wonder what the sudo rm -rf equivalent for windows is
Microsoft thinks it's uninstalling Edge.
That's all you really need to do to break windows. /s
Edge/Internet Explorer is/were a cornerstone of any Windows install. Uninstall that and you can get all kinds of weird issues on your system.
Like my auto-installed Copilot doesn't launch?
Oh no!
For some context, I've got a Windows install that I primarily keep around for VR gaming which I remove Edge from. That Copilot thing is the only "issue" I've noticed.
Windows doesn't have sudo(not yet, at least) and privileges work a bit different as even as an administrator, you may not have full rights.
To overcome that obstacle, you'd need to run a shell as an administrator (hold CTRL+Shift, then use the start menu entry or right-click it and select run as administrator).
Next obstacle: We have a separate drive for each partition, but no root folder.
If we assume we're running on a laptop or PC with a single drive and a single partition*, then it's just
In cmd.exe:
del /F /S C:\
In Powershell:
Remove-Item -Recurse -Force -Path C:\
When you want to delete all (mounted) partitions/drives, you need to iterate over them. (Note that's from the top of my head, didn't check the script if it works).
Done. Mounting additional partitions before that is left as an exercise for the reader.
*note that even a standard installation of windows creates 3 partitions. One for the bootloader, one for the recovery system and then the system drive. Only the latter is mounted and will be deleted by this. The other two will still be intact.
It has the neat built-in feature of rsyncing the high voltage SID collection to your computer.
However, if you deleted your local copy of it and tried to re-sync it'd update (with deletes) against / instead. Bye bye files.
I wonder how much would break, and how much time it would take to update everything, if all shells decided to implement a breaking change to prevent these kind of scenarios. E.g. make "set -u" default or some other solution
Trust but verify. It was a text file, it doesn't get much easier to do the second step of that.
... in which case you would have seen that they delete a path referenced by an env var being set earlier.
How likely do you think it would have been to notice, that this env var will turn up empty in your specific case?
A theme that deleted anything would have been enough of a red flag.
Hetken jo ajattelin, että mitä hiivatin noituutta nämä Suomeksi olevat konekääntäjän tekstit ovat olevinaan.
wiped clean?
It is windows users that pretend to be linux user.
rm -rf ${var}/is a disaster waiting to happen.Always do
rm -rf "${var:?}/"so that the script aborts if the variable is empty. Or better yetrm -rf "./${var:?}/".Edited to add quotes. Always quote a path: it might have spaces in it, without quotes that will become multiple paths! Which would also have avoided the particular bug in question.
Is there not also a way to disallow empty variables in the script, I think it is
set -u? Then you don't have to keep thinking "should I add a:?here because if empty it may lead to disaster" all the time. Might be even safer.set -euo pipefailat the top of every script makes stuff a lot safer. Explanation here.Yep! I always do this too.
TL;DR:
eaborts the whole script on a non-zero error.uaborts when using an undefined variable.-o pipefailaborts a piped compound command when one of the piped commands fail.Any other way lies madness. Or erasing the whole filesystem apparently!
Yes! But
-uis for undefined variables. It won't stop a defined variable with an empty value. E.gfoo="".Also
?and:?have the advantage of telling you right then and there where the variable use is that it must be defined or not empty... having to trek back to (likely) the top of the script to check is easily forgotten.Reminds me of a script a colleague has where it would sometimes accidentally wipe the entire production folder on a server. I pointed out the risk in his script and explained how to correct it like 2 years ago, give or take. He said he did, but then last week it happened again because apparently he had several scripts like that and only corrected one.
You can lead a horse to water, but you can't force it to drink.
In this case the issue was that a change between kde5 and kde6 let to the variable being defined as
somepath /(notice the space).And that's why you also surround it with double quotes.
I usually have a whole block that checks if the var exists and exits if not, but this is way more elegant
Protects you from accidentally changing the variable within the block too!
Reminds me of old bumblebee install script:
Yikes
That reminds me...
In circa 1995 I was running a dial upBBS service -- as a teenager. So if course, it was full of bootlegged video games and such, and people would dial in, download a game, log off.
Someone uploaded Descent or something like that. But they had put "deltree /y C:" or similar into a batch file, used a BAT2COM converter program, then a COM2EXE program, then padded the file size to approximately the right size with random crap (probably just using APPEND)... And uploaded it. Well, fortunately for the rest of my users, I say the game and said: oh, that's neat, I should try it and copied it to another computer over my internal network and launched it. It started deleting files right away and I hit CTRL-C to abort. I lost only a few dozen files.
Banned the user, deleted the package. Got lucky.
The theme contained rm -rf, but claims it wasn't malicious intent...I assume rm -rf for cleanup, but seems like it should have a apecific path other than /
The command was rm -rf $pathvariable
Bug in the code caused the path to be root. Wasn't explicitly malicious
Don't most distros have safeguards against this? I tried
sudo rm -rf /in an Ubuntu VM that I was about to delete just to see what happened, and it gave me a warning. I had to add some other option to bypass the warning.it apparently was defaulting to the home dir, not
/Oh, oof.
Hopefully most people take regular snapshots.
Yes,
rm -rf --allow-unsafeOr something is required
--no-preserve-rootWhen I worked at Pixar long ago an intern had a cron job that was intended to clean up his nightly build and ended up deleting everything on the network share for everyone!
Fortunately there were back-ups and it was fine, but that day was really hilariously annoying while they tracked down things disappearing.
Was that the infamous Toy Story 2 incident?
Amusingly enough, no.
This was after Toy Story 3 released but before Brave.
Oof
Was it a native theme or a downloaded/custom theme?
Downloaded from the KDE store
Thank you. I couldn’t get google translate to work for me.
Custom download
A Linux user's nightmare: the machine was wiped clean with one click
Timo Tamminen
One day a Linux user using KDE Plasma decided to download a generic theme for his desktop environment. This is possible with Plasma's built-in tool, through which you can download anything from themes to icons and wallpapers.
Installing themes using Plasma's tool is easy and fast. It practically only requires one click. This time, however, the user in question certainly wishes that that one click had not been completed.
Namely, installing the theme called Gray Layout wiped the machine completely empty of the user's personal files. Without asking anything.
Although the theme developer's intention this time was apparently not malicious, the accident was a clear indication that installing third-party themes without careful supervision can be a bad mistake. With the theme, almost anything can be installed in the user's home directory.
The Gray Layout installation script ran the rm -rf command, which normally removes all files from the device, making the command particularly dangerous to use. However, without root access, it can only cause limited damage.
Reddit user Jeansen Vaars says that he lost all his games, settings files, browser history and other contents of his home directory in a crash.
The unofficial face of KDE, Nate Graham, apologizes for what happened. He promises that the matter will be thoroughly investigated. The theme in question has also been removed from the theme store.
A theme is software and software has bugs. While this one had a pretty dramatic effect, you take basically the same risk with every program you run. This, along with hardware and user errors are why backups are so important; they change a disaster to an inconvenience.
/ Preach mode off
I honestly did not know that KDE themes contained executable code. When I think "theme", I think of cosmetic settings that plug into an existing program, which I would hope sanitizes its input and does NOT execute arbitrary code. I don't think "arbitrary executable code running as root".
I'm assuming KDE warns you about this when you try to install a theme, right? I'm not at my KDE system to test at the moment. I did try downloading a theme tar from the web site, and it doesn't seem to contain any code — just SVG files, a colors config file, and a metadata file.
It may help to know a bit of history: KDE3 themes could include a bespoke widget style, and QT3 widget styles were always implemented as executables (you can look at modified versions of the C++ code in the TDE git repository, if you're really bored). So keeping code out of the themes hasn't been important to KDE for at least the past 20 years. If I'm not mistaken, far more things are stylable in current versions of KDE. That doesn't mean that every theme will style all of them, though—you can have codeless styles like the one you found, that make use of the built-ins rather than trying to change All The Things.
Breeze, for example, contains a lot of code. For instance
A windows device just wiped the hardware settings of a periphery device, because it got an update and the new lighting settings wanted to control the LEDs in that device. All gone
Translation difficulties, or does the author really think that's what it's normally used for?
It's an accurate translation. Mikrobitti is a generic computer magazine (with a long history) so it could either be that the author is not very familiar with Linux cli or it might also be that they were trying to put it in layman's terms.
That's what good backups are for.
I image all my PCs daily with Veeam, bootable media is on my Ventoy USB stick, and restoring is easy as you just boot up the restore media and it pulls the latest backup over the network.
Click bait
I wonder what the sudo rm -rf equivalent for windows is
Microsoft thinks it's uninstalling Edge.
That's all you really need to do to break windows. /s
Edge/Internet Explorer is/were a cornerstone of any Windows install. Uninstall that and you can get all kinds of weird issues on your system.
Like my auto-installed Copilot doesn't launch?
Oh no!
For some context, I've got a Windows install that I primarily keep around for VR gaming which I remove Edge from. That Copilot thing is the only "issue" I've noticed.
Windows doesn't have
sudo(not yet, at least) and privileges work a bit different as even as an administrator, you may not have full rights.To overcome that obstacle, you'd need to run a shell as an administrator (hold CTRL+Shift, then use the start menu entry or right-click it and select run as administrator).
Next obstacle: We have a separate drive for each partition, but no root folder.
If we assume we're running on a laptop or PC with a single drive and a single partition*, then it's just
In cmd.exe:
In Powershell:
When you want to delete all (mounted) partitions/drives, you need to iterate over them. (Note that's from the top of my head, didn't check the script if it works).
In cmd.exe:
In Powershell:
Done. Mounting additional partitions before that is left as an exercise for the reader.
*note that even a standard installation of windows creates 3 partitions. One for the bootloader, one for the recovery system and then the system drive. Only the latter is mounted and will be deleted by this. The other two will still be intact.
SIDPlay did something similar on the Mac.
It has the neat built-in feature of rsyncing the high voltage SID collection to your computer.
However, if you deleted your local copy of it and tried to re-sync it'd update (with deletes) against
/instead. Bye bye files.I wonder how much would break, and how much time it would take to update everything, if all shells decided to implement a breaking change to prevent these kind of scenarios. E.g. make "set -u" default or some other solution
Trust but verify. It was a text file, it doesn't get much easier to do the second step of that.
... in which case you would have seen that they delete a path referenced by an env var being set earlier.
How likely do you think it would have been to notice, that this env var will turn up empty in your specific case?
A theme that deleted anything would have been enough of a red flag.
Hetken jo ajattelin, että mitä hiivatin noituutta nämä Suomeksi olevat konekääntäjän tekstit ovat olevinaan.
wiped clean?
It is windows users that pretend to be linux user.
They are root.