You Do Not Need ‘Sudo’ So Stop Using It
The constant advise to Linux/UNIX users to use sudo before many different commands is more common than it should be. Each time these words hit the internet, an angel loses its wings. Seriously, it’s a recipe for disaster. While this may seem overly dramatic, it is telling you to do something you don’t need to do which could destroy data in the long-run. Realistically anyone should be able to count the number of times they use su or sudo in a given year. Let’s go into why you don’t need this, and what you can do to avoid it.
Sudo and Security
The sudo command has always been an administrator’s nightmare, and something many of us thought would disappear after 2005. Back then it was common knowledge to never use sudo due to the large security risk that came with its use. The UNIX-based system’s security relies on strong walls of protection, one being that every user has their own password, and a root user who has the elevated privileges to alter the system files. For the longest time when using OSX, it was required to explicitly enable access the root user via sudo. Aside from OSX’s flaw allowing anyone to gain this access without a password when logged in, it still was not the easiest task to get into a Linux and UNIX (BSD) system.
Why Sudo is a Flaw: Explanation
The biggest flaw with today’s systems are the users, especially those with very little knowledge and understanding of the idea behind its security. Ubuntu’s default sudo access has set today’s standard, so root access is now accessed with a quick sudo command using the user’s password. This means sudo allows anyone to access the entire system with a single password. It also means that any user with a weak password, has made their entire system extremely vulnerable.
Note: There are also ways to secure sudo’s ability (never by default), but that goes outside of the scope of this article
Sudo, Files, and Folders, Oh Gawd
The main benefit of the root user’s access, is to protect the local system files. When you’re using it to run commands and alter projects, your system’s files and folders are in danger. With it you can literally wipe out your entire system with a simple mistake. This is the reason I become so furious when I read people suggesting to use the rf flags with the rm command.
Some of you may be pleading with me, “but my Python/Ruby/CocoaPods/Java needs sudo to be accessed”. No, it really does not. Interpreters that need escalated access are for the system. Such managers are system-specific interpreters and compilers put there to support libraries built into your system. These are not there for your personal use, and why files like this require system level access in the first place.
Using rm Responsibly
Quick question, do you know what the r and f flags do in conjunction with the rm command? First, the r tells rm to remove files recursively, meaning it will traverse the child folders. That sounds like everything you need, so why would you need the f flag? The short answer is: you don’t. Realistically, the f flag tells rm to force the removal of any file that needs special permission to be deleted.
These permissions that are being overridden are mostly used for system files, so using the f flag is telling rm “I know what I’m doing, so delete it!”. You are forcing the deletion of protected files. When you pair that with the r flag, you can end up with bad results.
Here is an example of where this can be a disastrous issue. Let’s say we type:
# sudo rm -rf /home/username/dev/projectnameOf course, once it’s a habit you’ll inevitably start typing it fast. But it only takes an added space after the f flag, and you end up with this instead:
# sudo rm -rf / home/username/dev/projectnameGuess what happens? rm starts to delete everything in the / folder which signifies the root folder of your system. If you notice your mistake in time, you may be able to salvage part of your system. With a SSD drive, you can almost guarantee your system will be hosed. This is all due to someone telling you to add the force flag to your rm command with sudo, and now your system is screwed with a capital F.
Folder Security
So, if you are ever told to use the chmod command to give the permissions 777, you 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, keeping anyone else from removing or overwriting them without your permission.
Folder Permissions
What do the numbers mean? 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. When you add those numbers up, you end up with 7 which signifies all three permissions. Offering permissions like 4 (Read), or 5 (Read/Execute) are more common permissions for the group and world, and even 0 (no access) for world in protected areas. A good suggestion is using 755 or even 740 for your project folders, because you are the one that needs access and very rarely anyone else.
Using ls -l to list files will show the permissions as rwx (read/write/execute) for each group. You can also use these same characters to set permissions. With the chmod command you can change these permissions, and can use r, w, and x to interpret access. The octal method is much more terse, but an option exists where you may learn more simply by typing man chmod.
Project Directories
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. It uses permissions that do not require super-user access, placing the files in the user’s folders. A good example of this particular issue in OSX, is using the system’s Python installation for development.
Responsible Project Environments for Ruby, Python, and CocoaPods
For those who are using built-in language-based package managers, it is as simple as installing the same package managers within user-land. When using OSX you can use HomeBrew to install ruby and python in user-land:
$ brew install ruby
$ brew install ruby && gem install pods
$ brew install python
Linux/BSD users can use something just is as simple. The difference being using the package manager that comes with your system (apt / yum / pkg_add / emerge ). 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.
Responsible Project Environments for JavaScript
The one answer I do not see from anyone, at least very rarely, is to put your projects in user-land. This means in the area where you can access it, including your NPM packages. Using sudo to install NPM packages is a bad idea, so stop now! You can install everything in your own home folder, and make everything accessible!
When you have already installed packages with sudo, and you do not know how to safely remove these packages, leave them alone, or start running “npm un <package name>” for each one. Just make sure to ignore anyone telling you how to go to the /usr/lib folder and remove them manually. When you do not know what you are doing, its best to just leave it alone. Seriously the disk space is not that important.
First thing on the list is to change the folder prefix, which 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!
If you install something like npm version, jest, mocha, react-native, linters, or anything else that requires you to run commands globally, you never need to use sudo. These files are yours, and will never require you to escalate your privileges to change.
Summary
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. In most cases, there is an option for installing development tools within user-land.
Happy coding!
No Comments