Paranoid Penguin - Linux Filesystem Security, Part II
I want to cover one last command specific to permissions before closing with a couple of other topics. umask is a command built into the bash shell that prints or sets your default permissions mask. To see yours, simply enter the umask command without any arguments; it returns a four-digit number. On my system, it looks like Listing 3.
Listing 3. Checking My Default Permissions Mask
mick@localhost:/home/mick> umask 0022
Mode 0022 means no special permissions, no user-owner permissions, group and other permissions set to write, right? How can that be?
Actually, umask deals in masks, not in modes per se. 0022 is what is subtracted from the number 0777 to determine the numeric mode of files you create: 0777 – 0022 = 0755.
Aha! So, files I create have user-owner permissions set to read-write-execute (7 = 4 + 2 + 1) and group and other permissions set to read-execute (5 = 4 + 1)? Right? Almost. It also happens that umask sets the execute bit automatically only on directories. Even if your permissions mask includes execute permissions, the execute bit does not set automatically on regular files you create. So, if my permissions mask is 0022, resulting in default permissions of 0755, and I create a file named default_file and a directory named default_dir, long listing output for those two items look like Listing 4.
Listing 4. File and Directory with Mask of 0022
-rwxr-xr-x 2 mick users 48 2004-08-13 08:31 default_dir -rw-r--r-- 1 mick users 4 2004-08-13 08:31 default_file
To change your default permissions mask, simply issue the command umask with the new mask as its argument. For example, if I want all my files to have group-read permissions but no other permissions, this translates to a numeric mode of 0740. If I subtract that from 0777 I get a mask of 0037. Therefore, the umask command I enter is umask 0037. This new mask, however, applies only to my current session and any new shells I start from it. To make it persistent, I can add the line umask 0037 to my .bashrc file.
I should say a few words about the reality of users, groups and permissions. The whole problem with UNIX security is that far too often, permissions and authority on a given system boil down to root can do anything, although users can't do much of anything.
Sadly, it's much easier to do a quick su - to become root for a while than it is to create a granular system of group memberships and permissions that allows administrators and sub-administrators to have exactly the permissions they need. Sure, you can use the su command with the -c option, which allows you to specify a single command to run as root rather than an entire shell session (for example, su -c rm somefile.txt), but this requires you to enter the root password. It's never good for more than a small number of people to know root's password.
Another approach to solving the root-takes-all problem is to use role-based access control (RBAC) systems, such as SELinux, which enforce access controls that reduce root's effective authority. However, this makes things even more complicated than setting up effective groups and group permissions. This is not to say that SELinux and the rest aren't good things—I love RBAC.
A better middle ground is to use the sudo command. sudo is short for superuser do, and it allows users to execute single commands as root, without actually needing to know the root password. sudo is now a standard package on most Linux distributions.
sudo is configured with the file /etc/sudoers, but you shouldn't edit this file directly. Rather, use the visudo command, which opens a editor on the file; vi is the editor by default. You can use a different editor by setting the EDITOR environment variable. For example, to use /usr/bin/gedit, do this:
Space doesn't permit me to explain sudoers' syntax in detail; see the sudoers(5), sudo(8) and visudo(8) man pages for complete information. In the space available here, let's run through a quick example.
Remember the user crash's quest to rid the world of Pineapple-Mushroom Surprise? Although in this case it would be overkill—the permissions techniques I've already illustrated are sufficient—you could use sudo to allow crash to realize his goal, assuming you (biff) have root privileges. First, become root (su -). Next, execute the command visudo. You're now in a vi session, editing the file /etc/sudoers; see the vi(1) man page if you're new to vi. Go down to the bottom of the file and add this line:
crash localhost=/bin/rm /home/biff/extreme_casseroles/pineapple_mushroom_surprise.txt
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- August 2015 Issue of Linux Journal: Programming
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development