Javascript is a programming language with a peculiar twist. Its event driven model means that nothing blocks and everything runs concurrently. This is not to be confused with the same type of concurrency as running in parallel on multiple cores. Javascript is single threaded so each program runs on a single core yet every line of code executes without waiting for anything to return. This sounds weird but it's true. If you want to have any type of sequential ordering you can use events, callbacks, or as of late promises.
| Test Cloudflare 2025-02-22 17:52:41 (Epoch: 1740243161) -- Dibimobil. | |
| Ranges Alive: 4261 | |
| Ranges blocked: 1695 | |
| 103.21.244.0/24 | |
| 103.21.245.0/24 | |
| 103.22.202.0/24 | |
| 103.31.4.0/24 | |
| 103.31.5.0/24 | |
| 103.31.6.0/24 |
| #!/bin/bash | |
| # | |
| # https://github.com/Nyr/openvpn-install | |
| # | |
| # Copyright (c) 2013 Nyr. Released under the MIT License. | |
| # Detect Debian users running the script with "sh" instead of bash | |
| if readlink /proc/$$/exe | grep -q "dash"; then | |
| echo "This script needs to be run with bash, not sh" |
| These commands are based on a askubuntu answer http://askubuntu.com/a/581497 | |
| To install gcc-6 (gcc-6.1.1), I had to do more stuff as shown below. | |
| USE THOSE COMMANDS AT YOUR OWN RISK. I SHALL NOT BE RESPONSIBLE FOR ANYTHING. | |
| ABSOLUTELY NO WARRANTY. | |
| If you are still reading let's carry on with the code. | |
| sudo apt-get update && \ | |
| sudo apt-get install build-essential software-properties-common -y && \ | |
| sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y && \ |
Let's say somebody temporarily got root access to your system, whether because you "temporarily" gave them sudo rights, they guessed your password, or any other way. Even if you can disable their original method of accessing root, there's an infinite number of dirty tricks they can use to easily get it back in the future.
While the obvious tricks are easy to spot, like adding an entry to /root/.ssh/authorized_keys, or creating a new user, potentially via running malware, or via a cron job. I recently came across a rather subtle one that doesn't require changing any code, but instead exploits a standard feature of Linux user permissions system called setuid to subtly allow them to execute a root shell from any user account from the system (including www-data, which you might not even know if compromised).
If the "setuid bit" (or flag, or permission mode) is set for executable, the operating system will run not as the cur