Speaking UNIX, Part 4
UNIX ownership and permissions provide for privacy and participation
Share and share alike
This content is part # of # in the series: Speaking UNIX, Part 4
This content is part of the series:Speaking UNIX, Part 4
Stay tuned for additional content in this series.
From the dawn of the electronic age a scant 50 years ago until the launch of the Apple computer in 1977, computing hardware was scarce and extremely expensive to acquire and operate. What cycles could be eked out of (the relatively) primitive systems of the day were precious commodities, grudgingly allocated to only the most vexing problems. Projects vied to get computer time, and the earliest information technology (IT) managers worked to keep systems busy 24 hours per day, seven days per week. After all, an idle tick was money wasted.
Ideally, those lost ticks would be allocated on demand and automatically to any ready task awaiting computation. And indeed, that's the idea (first proposed by Robert Berner as early as 1957) behind time-sharing. As realized in Multics, RSTS/E, and later UNIX® and its many modern variants, time-sharing, or multitasking, divides a computer's resources (the CPU, input and output, and memory) among awaiting jobs, creating the illusion that every job has exclusive use of the machine. Attach several dumb terminals to a multitasking mainframe and each terminal appears to be a personal computer.
Nowadays, it's quite likely that you have your own UNIX computer and share an even more powerful multi-processor system with others. Yet in both cases -- your laptop and the UNIX behemoth in the corporate machine room -- simultaneous access remains fundamental. UNIX provides robust tools and infrastructure so that you can both protect and share information.
This article looks at user privileges and, in particular, examines how to manipulate file permissions to restrict or share your directories and files with others. Understanding permissions is crucial if you want to speak UNIX fluently.
The id, the ego, and the UID
To start, let's explore just who you are. At a command prompt, type
$ whoami strike
My computer answers
strike, which is my user name (the same name I use to log in). Your
whoami should return your login name.
As it turns out, your user name is really a pseudonym for your user ID (UID). To see your UID, type
$ id -u 501
Here, my UID is 501.
In general, user names are used whenever possible instead of UIDs simply because they're human-readable and easy to remember. For example, if you run the
ps uxf command to see a list of your running processes,
ps displays your user name as the owner of
$ ps uxf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND strike 32346 0.0 0.1 6496 1832 ? S 19:39 0:00 sshd: strike@pts/0 strike 32347 0.0 0.1 2592 1476 pts/0 Ss 19:39 0:00 \_ -bash strike 32358 0.0 0.0 2476 820 pts/0 R+ 19:39 0:00 \_ ps uxf
The output shows three running processes: an ssh login, which spawned a
bash shell, which launched the
ps command itself. Similarly, if you run
ls -alFG in your home directory to view the owners of your files, your user name is displayed instead of your UID.
In general, only you can interrupt your tasks. (Of course, the superuser, root, can control and manipulate all tasks.) For example, joe, another user sharing the same system, cannot terminate my running shell, which is process 32347 in the list above:
$ whoami joe $ kill -INT 32347 -bash: kill: (32347) - Operation not permitted
32347 is the process ID of my shell, which joe can find by running
ps auxf. However, because I own the process, joe cannot terminate it. In contrast, I can certainly kill any of my own tasks, as shown in Listing 1.
Listing 1. Kill your own processes
$ ps uxf ... strike 32347 0.0 0.1 2592 1488 pts/0 Ss 19:39 0:00 \_ -bash strike 32733 39.5 0.0 1480 356 pts/0 R 19:50 0:01 \_ yes $ kill -INT 32733 $ ps uxf ... strike 32347 0.0 0.1 2592 1488 pts/0 Ss 19:39 0:00 \_ -bash
kill -INT 32733, process 32733 (the
yes command) is terminated.
While a relatively simple concept, strong ownership rights and per-user provisioning are two features that make UNIX far more secure than, say, Microsoft® Windows®.
Membership has its privileges
Like the jobs you launch, you also own the directories and files you create. For example, run the
ls -alFG command on your home directory and
$HOME to see what you own, as shown in Listing 2.
Listing 2. List what you own in the home directory
$ ls -alFG $HOME ... -rw------- 1 strike 6175 Aug 25 07:03 .bash_history -rw------- 1 strike 567 Apr 20 2005 .bash_profile -rw------- 1 strike 1834 Apr 20 2005 .bashrc drwx------ 2 strike 4096 Mar 8 10:54 .ssh/ -rw------- 1 strike 9516 Aug 22 16:42 .viminfo -rw-r--r-- 1 strike 1529617 Jul 19 07:00 Archive.zip drwxrwx--- 3 strike 4096 Aug 24 04:04 IBM/ drwxr-xrwx 3 strike 4096 Jun 14 06:06 backups/ ...
As you can see, I own all the directories and files in my home directory. As the owner, I can delete, rename, and move any of my files and directories, and I can edit any of my files. You have the same rights for your files (files means files and directories collectively, unless a specific exception is made).
In addition, you can elect to share your files with others. Indeed, because UNIX was designed as a multi-user system, sharing files is another principle tenet of the operating system.
In addition to a specific user owner, every file and directory also has a group owner. A UNIX group is simply a collection of users, and you can be a member of one or more groups. Use
id to discover your memberships:
$ id uid=501(strike) gid=501(strike) groups=501(strike), 81(appserveradm), 79(appserverusr), 80(admin)
On my system, my primary group is group id (GID) 501, or the group named strike. I also belong to three other groups:
Typically and by default, the group owner of a file that you create is your primary group, but you can subsequently change the group owner to any of the groups that you belong to. Run
ls -laF on your home directory to reveal more about your files, as shown in Listing 3.
Listing 3. Discover more about your files
-rw------- 1 strike strike 6118 Aug 27 21:59 .bash_history -rw-r--r-- 1 strike strike 567 Apr 20 2005 .bash_profile -rw-r--r-- 1 strike strike 1834 Apr 20 2005 .bashrc drwx------ 2 strike strike 4096 Mar 8 10:54 .ssh/ -rw------- 1 strike strike 9516 Aug 22 16:42 .viminfo -rw-r--r-- 1 strike strike 1529617 Jul 19 07:00 Archive.zip drwxr-xr-x 3 strike strike 4096 Aug 24 04:04 IBM/ drwxrwxr-x 3 strike admin 4096 Jun 14 06:06 backups/
Note: Listing 3 displays the typical output of
ls -l. Listing 2 looks different because the group owner was intentionally hidden to simplify the earlier discussion. You can hide the group owner with
The directory named backups has group owner admin, which extends certain privileges to all the members of that group. Meanwhile, the group owner of the rest of my files is strike. Typically, a user is the only member of his or her eponymous group, which effectively limits access solely to the user.
The fine details
If you glance back at the output of
ls above, you'll likely notice a sequence of 10 characters at the beginning of each line. Each character is an off or on setting, or bit, representing a specific right for one of three constituencies: you, one of your groups, and others. Figure 1 shows the uses of each bit.
Figure 1. The permission bits of a UNIX file
In Figure 1:
- The initial bit indicates whether the file is a directory. (In general, the initial bit indicates whether a file is special. If the file is special, the initial character is d for directory and l for symbolic link, among others.) This setting is immutable.
- The next three bits (shown in blue) represent your right to read, write, and execute the file, respectively. You might disable your write bit, for example, to prevent the file from being deleted. (Yes, you need write permission to delete a file.)
- The next three bits (in green) represent a group's right to read, write, and execute the file.
- The final three bits (in orange) represent the rights of every other user (that is, all users, excluding yourself and the members of your group).
ls -laF output found above as examples:
- The files .bash_history, .bash_profile, .bashrc, and .viminfo are readable and writable only by me. I can view, edit, and delete these files.
- The .ssh directory is accessible only by me. The first bit indicates that it's a special file, and the d stands for directory. I can display the contents of the directory because its user-read bit is set. I can add and remove files from the directory, because its user-write bit is set. You might be wondering why the directory is user-executable, as well. A directory cannot be traversed (entered and cataloged) unless this bit is set. (By the way, as mentioned in Part 3 of this series, your .ssh directory must be private to you, or your public key access won't work.)
- I can read and write the file Archive.zip, and others can read the file. (Of course, the strike group can also read the file, but if I'm the only member of that group, the permission is somewhat moot.)
- I can catalog, read, and write files in IBM, another directory, and others can catalog its contents.
- Finally, the members of the admin group and I can catalog, read, and write files in backups, and everyone else can catalog and read.
You modify permissions (except for the directory bit) by using the
chmod (change mode) command. You manipulate a file's group assignment by using the
chgrp (change group) command. (The superuser, root, can also change file ownership by using the
chown, or change owner, command.)
Here are example applications of
chmod u+x script.sh: If you write a shell script and want to execute it, enable its execute bit. Here, the phrase
u+xmeans for the user owner (
u) to enable (
+) the execute bit (
x). The general form of
chmodis chmod, none (which implies user), one, or more of
g(for group), or
o(for others), a
-, and one or more of
chmod go+rx IBM: This command enables the read and execute privileges for group and others.
chmod a+rx script.sh: In addition to
o, you can use the modifier
afor all or user, group, and others. Thus, this command enables read and execute for all three constituencies.
chgrp admin backups: This command changes the group owner to admin.
If you add permissions with
+, it adds the specified permissions but leaves other permissions untouched. Similarly, if you retract permissions with
- (minus), it disables certain permissions but otherwise leaves the status quo. If you want to set all the permissions at once, use numeric file modes. (You can also use the
chmod = operator. See the man page for details.)
Note: A numeric file mode is a octal digit from 0 to 7, or a three-bit number, one bit for each of read, write, and execute. Because there are three constituencies for each file, a fully specified file mode is three digits, such as
777. Here are some examples:
- To make a directory private, you enable rights for yourself but retract the rights for a group and others:
$ mkdir example $ ls -l drwxr-xr-x 2 strike strike 68 Aug 28 11:27 example $ chmod 700 example $ ls -l drwx------ 2 strike strike 68 Aug 28 11:27 example
700translates to enable read, write, and execute for user (the leading
7), but disable all other permissions (the two latter zeroes).
- If you want to let everyone else on your computer read one of your files, enable the read permission for all three constituencies:
$ ls -l .aliases -rw------- 1 mstreich mstreich 79 Jul 26 17:08 .aliases $ chmod 644 .alias $ ls -l -rw-r--r-- 1 mstreich mstreich 79 Jul 26 17:08 .aliases
644is a shorthand for set, read, and write permissions for me (
6), and read for group (
4) and others (
4). Of course, if the file .aliases was in your home directory, the permissions for $HOME would have to permit cataloging and reading.
The chart in Table 1 presents numeric values and the associated result for user owner, group owner, and others. Simply add the values in each section to find the proper value to set.
Table 1. Numeric values and associated results
|User||0400||Allow read by owner.|
|0200||Allow write by owner.|
|0100||For files, allow execute by owner; for directories, allow the owner to search in the directory.|
|Group||0040||Allow read by group members.|
|0020||Allow write by group members.|
|0010||For files, allow execute by owner; for directories, allow group members to search in the directory.|
|Others||0004||Allow read by others.|
|0002||Allow write by others.|
|0001||For files, allow execution by others; for directories allow others to search in the directory.|
For example, to set read and write privileges for others, add
0002 to yield
0006. Do something similar for user and group and add all three sums to yield a fully qualified numeric mode.
Permissions are fundamental
Setting and managing permissions comes up again and again on UNIX systems. You often need proper permissions on specific files and directories to run daemons; directories, such as /tmp, work only if correct permissions are set; and, of course, to share files with others -- or to protect your files -- you must be able to set, change, and read permissions.
The next article in this series continues with files and explores utilities and techniques to manage hundreds or thousands of files on multiple computers.
- Speaking UNIX: Check out other parts in this series.
zshMailing List Archive: Read this list to learn more Z shell tricks and tips.
- IBM trial software: Build your next development project with software for download directly from developerWorks.