Linux Nitty Gritty: Working at the Ubuntu Command-Line Prompt (2011)

Changing ownerships and permissions

Files or folders can have their ownership and group reassigned, but root powers are usually needed to do so.

NOTE A user can reassign the file’s group without root powers, but only if they’re a member of that group.

The owner of a file or folder can change its permissions so that read, write and execute permissions are either added or removed. Root powers aren’t needed for this.

Changing file ownership and group assignment

The chown (change owner) command is used to change a file or folder’s ownership. It must be preceded by sudo, because changing a file or folder’s ownership requires root powers.

The following will switch ownership of the file report.doc to the user frank:

sudo chown frank report.doc

The chgrp (change group) command is used to reassign a file or folder’s group. The following assigns the file report.doc to the accounts group:

sudo chgrp accounts report.doc

However, you can reassign the owner and group in one fell swoop by using chown and separating the new owner and group assignment with a colon. The following will change the ownership of report.doc to frank, and change the group assignment to accounts:

sudo chown frank:accounts report.doc

Changing file permissions

The chmod (change mode) command is used to alter permissions.

There are various ways of using the chmod command, but the easiest is to first specify who you want to alter the permission for (owner, group, or others) and then specify the permission changes (i.e. whether to add/remove read, write or execute permissions). Following this, the file or folder name should be specified.

Whom permissions should be changed for is indicated by u, g or o, standing for user (i.e. owner), group or others. The letter a can be used to indicate all three.

The permissions are indicated by r, w or x for read, write or execute, and whether the permission should be added or removed is indicated by the use of a plus or minus symbol (+/-).

Let’s go back to the file report.doc that, you may recall, had the following permissions and user/group ownerships:

rw-r--r-- keir keir

The owner can read/write to the file, but everybody else (group and others) can only read the file.

If we wanted to allow members of the group to be able to write to the file, we could type the following:

chmod g+w report.doc

In other words, this adds (+) write permissions (w) for report.doc’s group (g).

If we were feeling generous and wanted to let other users to write to it too, we could type the following:

chmod o+w report.doc

This adds (+) write (w) permissions for others (o).

On the other hand, if we wanted strict secrecy so that only the file’s owner could read or write to the file, and nobody else, we could type the following:

chmod go-rw report.doc

This removes (-) read and write permissions (rw) from report.doc for the group and others (go). If anybody apart from the owner should subsequently try to view or modify report.doc, they’ll get a “Permission denied” error.

TIP A quick way of removing all permissions for a type of user is to use the equals sign (=). For example, to remove all permissions for the group, you’d type chmod g= report.doc. This is the equivalent of typing chmod g-rwx report.doc.

Changing folder permissions

Folders are handled in the same way, although to allow/deny access to the folder, the execute (x) permission is set/unset.

The following will stop everybody apart from the folder’s owner reading a file listing of the Documents folder, reading/writing files, and switching into the folder:

chmod go-rwx Documents

In other words, this makes the folder entirely private.

NOTE Don’t forget that the root user can access all files and folders, no matter what their ownership or permission. It’s worth mentioning with respect to privacy that the Ubuntu boot menu’s Recovery option allows anybody using the computer to login as root, with no password required. Because of this, true privacy of files is only guaranteed via encryption.

Subfolders within a folder inherit the execute permissions of the parent folder. In other words, if it’s not possible to access the Music folder because the execute permission isn’t set, you won’t be able to access a folder within it even if permissions are set correctly for that subfolder.

Special permissions

In addition to read, write and execute, there are three other types of permission you might encounter: Set user ID (SUID, or SETUID); Set Group ID (SETGID); and the “sticky bit”.

These might be described as specialist permissions with specific system administration uses, and it’s unlikely you’ll need to make use of them day-to-day. They operate as follows:

Set User ID: In its most typical use, the SUID permission allows a program to run as if the program’s owner was running it (in other words, it runs with the permissions of the file owner, rather than the user who’s running it). It’s most commonly used to allow ordinary users to run programs with root powers, without the need to use sudo or switch to root user first. Such a program would be owned by root, will be set as executable, and have the SUID permission set. The s permission must be specified with chmod to set SUID (i.e. sudo chmod u+s programname). The SUID permission shows-up in long file listings as an s in place of the usual x that marks an executable file (i.e. -rwsr-xr-x).

NOTE Under Ubuntu the SUID permission has no relevance when applied to folders, and is ignored if set.

Set Group ID: As with SUID, the Set Group ID permission causes a program to run with the permissions of its group. However, SETGID is mostly used with folders, where it forces all files or subfolders created within the folder to inherit the group permission of the folder, rather than the user who created it. As above, the s permission is specified (i.e. chmod g+s myfolder), and the permission shows up as s in file listings.

Sticky bit: When set on a folder, the sticky bit means that only the owner of a file or subfolder within that folder can delete it (although the owner of the folder itself will be able to delete the file, as can root). The sticky bit is useful for folders where files are shared, but the administrator doesn’t want users to be able to delete any other user’s files. The sticky bit is indicated in file listings by a t at the end of the permission listing (i.e. drwxrwxrwt), and is set by typing chmod +t foldername. When applied to a file within Ubuntu, the sticky bit is meaningless and is ignored.

NOTE Should you see a capital S or capital T within file listings, instead of lower case letters, the execute permission hasn’t been set for the relevant file or folder. Although SUID and sticky bits normally rely upon the file/folder being executable, they don’t automatically set it.

Table 5-2. bash keyboard shortcuts.

bash productivity tricks

bash is the result of many years of computing research, and has evolved into an ultra-efficient piece of software.

The key to being a bash master is to make use of keyboard shortcuts, and the command history—essentially, a list of commands you’ve already issued. Additionally, bash has built-in job management. This means you can start a program, switch it to the background, and get on with something else while it completes.

Keyboard shortcuts

Table 5-2 lists bash keyboard shortcuts with reference to a modern PC keyboard. Some of the shortcuts refer to the command history, as explained in the next section.

Perhaps the most useful keyboard shortcut is to hit the Tab key. This autocompletes commands and/or filenames. Most commands are short enough to be typed manually, but some filenames and paths can be long and therefore irritating to type.

Say you wanted to delete (rm) the file verylongfilename.doc. You could type rm very and hit Tab to autocomplete the filename.

Give Tab autocomplete a try. It’s more intuitive than it might sound.

TIP Tab autocomplete also works when installing programs using the apt-get or dpkg commands. It will autocomplete package names based on what’s in the repositories.