As I continue to visit StackExchange and the infamous Stack Overflow to find quick answers to obscure errors, I continue to see the constant advise to Linux and OSX users, “use sudo” before your commands. For every time I read these words I grit my teeth, grind them, and clinch my fist wishing I could meet the face of these ignorant sheeple through my screen with my fist. While this may seem very overly dramatic, what would your reaction be to anyone telling you to inadvertently destroy your system, or leaving a ticking timebomb on your laptop? Let’s reflect upon this, as well as the alternatives.
Sudo and Security
First and foremost sudo has been an administrator’s nightmare, and something many of us thought would disappear after 2005 when it was common knowledge to never use sudo due to the large security risk that came with its use. While Linux and BSD’s (FreeBSD being the meat of OSX) security relies on their strong kernels, strong walls of protection via services, and obscurity, the main security feature is that every user has their own password, as well as the root user who has the elevated privileges to alter the system files. For the longest time when you used OSX it required you to explicitly turn on the ability to access the root user via sudo. Aside from OSX’s flaw allowing anyone to gain this access without a password while logged in, it was not the easiest task for any attacker to get into a Linux and UNIX (BSD) system.
Why Sudo is a Flaw: Explanation
Unfortunately the biggest flaw with today’s systems are the users, especially those with very little knowledge and understanding of its security. With Ubuntu’s default sudo access to set today’s standard, root access is now accessed with a quick sudo command and the user’s password. If you haven’t caught on yet sudo allows anyone to access the entire system with a single password, instead of having the extra security provided by the root account’s own password. This means that any user with a weak password of their dog’s name, birthday, or some simple dictionary word has allowed their “secure system” to become extremely vulnerable. Perfect!
Note: There are some ways to secure sudo’s ability, but that goes outside of the scope of this article
Sudo, Files, and Folders, Oh Gawd
To reiterate the fact, one of the main benefits of root access is to protect the local system files. If you are running commands, and altering projects, your system’s files and folders are no longer safe at all; you can literally wipe out your entire system with a mis-typed command. This is also the reason I become so furious when I read people suggesting to use the rf flags in conjunction with the rm (remove file) command.
Of course you may be pleading with me, “but my Python/Ruby/CocoaPods/Java needs sudo to be accessed”. No, no it does not. What needs that access is the system’s version of these language interpreter. If you feel you need to use what is built-in especially the version of said interpreter/compiler your system is using, and not to sound harsh, but you need to re-evaluate your decisions in life. Let me help by mentioning that these are system-specific interpreters and compilers put there to support libraries built into your system, and is not there for your personal use, and thus there is always a reason files like this require system level access in order to alter.
Using ‘rm’ Responsibly
Does anyone know what the r and f flags do in conjunction with rm? First off r tells the rm to remove files recursively, meaning it will traverse the folders in the target directory deleting everything it finds. When removing projects, that does everything you need, right? Exactly, it does! So why would you need the f flag? Short answer, you don’t. The f flag tells rm to force the removal of any file that needs special permission to be deleted.
These sorts of permissions are rarely needed for much more than system files, but using the f flag is telling rm to say “f@%k it” and delete them anyways, because you are forcing the deletion of these files. Match that with the r flag and you could end up in some serious trouble. Awesome huh?
Here is an example of where this can be a disastrous issue. If you ever type in the command:
# sudo rm -rf /home/username/dev/projectname
After getting use to typing this out enough times, you may find yourself typing so fast, and the next thing you know you have added an extra space after the f flag, and type this instead:
# sudo rm -rf / home/username/dev/projectname
Guess what happens? rm starts to delete everything in the / folder which is the root of your entire system. If you notice it in time you may be able to salvage part of your system, but it does go in order of threads, which means your system will be hosed, especially if you are running with a SSD drive. So all because some ignorant person on Stack Overflow told you to use sudo as well as the rf flags with your rm command, your system is screwed with a capital F.
If you are ever told to use the chmod command to give the permissions 777 it may be wise to ignore that as well. This was a new one to me up until today, but this would be a great time to cover folder permissions really quick. These three numbers represent the three types of permission you can give files and folders in a UNIX-based system. Having the correct permissions can keep your files safe, and keep anyone else from removing or overwriting them without your permission.
So what do the numbers mean you may ask? The first number controls the user’s permissions, the second is for the group that is set to the file, and the last number is for the world (everyone). It should be obvious that you do not want to give the world the same access you would give yourself, but that is exactly what 777 does.
These three numbers are binary totals that represent the permission types, but to spare the deep explanation let’s look at the fundamentals. Each number represents three different permissions (in the simplest case at least), read, write, and execute. Execute is the value 1, Write is the value 2, and Read is the value 4. So if you add those numbers up you end up with 7, meaning all of these permissions. Offering permissions like 4 (Read), or 5 (Read/Execute) are more common permissions for the group and world when setting these, and even 0 (no access) for world. So I would suggest using 755 or even 740 for your project folders, because you are the one that needs access, and very rarely anyone else.
When using ls -l to list files, you can see the permissions as rwx (read/write/execute) for each group, and you can also set permissions this way. When using the chmod command to change these permissions, you can use r, w, and x to add these values. Of course the octal method is much more terse, takes less time, but the option exists where you can learn more by typing man chmod.
There are many languages that will put files and folders in user owned folders, and that includes the default behavior of many Linux and UNIX packages and ports. If you find yourself having issues with system permissions in OSX, you are probably installing packages manually where you would instead want to install your language packages through HomeBrew. Aside from being an almost mandatory package manager for OSX developers, it also adds package installations to an isolated system directory, but with permissions that do not require super-user access, but most importantly placing the constantly changing user files in user folders. An example of this particular issue in OSX is using the system’s Python installation for development, which is not a great idea.
Responsible Project Environments for Ruby, Python, and CocoaPods
For those who were using built-in language libraries, it is as simple as installing the language libraries to have support within userland. In OSX this is as simple as running a single command with HomeBrew (which you should have) :
$ brew install ruby
$ brew install ruby && gem install pods
$ brew install python
For other Linux/Unix users this is as simple as the OSX instructors, except you are using whatever package manager your system comes with (apt / yum / pkg_add / emerge ).
There is nothing more to it. You end up with your own copy of the libraries which you can easily upgrade, leaving all of the system files untouched like they should be.
The first thing you are going to do is change the folder prefix, and this tells NPM where to install all of your global packages. I like to use the following setting:
npm config set prefix ~/.npm
Using this setting will tell NPM to install all of your global packages into the hidden folder .npm inside your home folder (~/ is a shortcut to your home dir). That’s it!
Now when you install something like npm version, jest, mocha, react-native, linters or anything that requires you to run commands globally, you NEVER have to use sudo to prefix the command. These files are yours, and will never require you to escalate your privileges to use. Develop in peace, and do not ever let the ignorance of others keep you from moving forward with your projects. If you are having to use sudo for development, revisit your options, there is almost always an option for installing development tools within userland. Happy coding!