Originally Published: Thursday, 16 September 1999 Author: Joshua Go
Published to: news_learn_firststep/Firststep News Page: 1/1 - [Printable]

Using chmod

chmod has a bit of a bad reputation for being confusing. I'll be honest with you: at first, it makes very little sense. You just have to be patient and try to understand the basics. This document aims to help you in gaining that understanding.

   Page 1 of 1  

chmod has a bit of a bad reputation for being confusing. I'll be honest with you: at first, it makes very little sense. You just have to be patient and try to understand the basics. This document aims to help you in gaining that understanding.

Basic Unix Filesystem Security (UID, GID, and permissions)

Knowing the basic Unix filesystem security issues will help you dramatically. Explained here are concepts to make your understanding of these issues skyrocket. Well, that's what we'll try to do, anyway.


In Unix, every user is a member of a group. For example, when you add a user, that user is normally a member of the group users. Almost all users are members of the group users. Notable exceptions are normally members of wheel or admin, the administrative groups. Note that the computer doesn't see the username when it does anything, but it sees a user ID. A user ID is (technically) a number, while a username is a string associated with that number (in pseudo-C, it's char *usernames(userid)). The same holds true for groups and group IDs. User ID is normally abbreviated "uid" and group ID is normally abbreviated "GID". I'll use these abbreviations from here on out.


Each file in the directory structure is owned by a user. Each user is owned by a group. To keep things flexible, each file is also owned by a group - by default it's owned by the group that owns the user.

Why This Stuff is Important: Permissions

Permissions define what users of various groups can do with the file. There are three basic things you can do with any file: read from it, write to it, and execute it. Permissions is based on this concept, combined with UID/GID, and the hierarchy of users/groups.

You set permissions using the chmod command, and you can do it one of two ways: with letters or with numbers. Numbers is the preferred method (fairly easy to use, once you get the hang of it). In fact, I feel that letters are about useless, unless you are doing advanced tasks (and by the time you know enough to need such functionality, you should be able to read man pages). Understand that I'm simplifying things a bit - for a better reference see man chmod - but this information should be enough to get you through most normal maintenance tasks.

chmod by the Numbers

The basic format for chmod is chmod xyz file.foo. x, y, and z are each a number between 0 and 7. Each number represents the permissions of a group - x is for the user that owns the file, y is for the group that owns the file (normally the user's group), and z is for everybody else. To determine the actual values for each number, you use the following method: start with x = 0. If you want to be able to read from the file, add four. x can be 0 or 4 at this point in time. If you want to be able to write to the file, add two. x can now be 0, 2 (a write-only file??), 4 (read-only file), or 6 (read/write file). If you want to be able to execute the program, add one. You now have a full range of possible numbers:

     Number  | Permissions
       0     |   None - cannot read or write or execute 
       1     |   Can execute, but cannot read or write
       2     |   Write-only, cannot read or execute (??)
       3     |   Write-able/executable
       4     |   Read-only, cannot write to or execute
       5     |   Read-only executable, cannot write to
       6     |   Readable Writeable file, but not executable (ie: text file)
       7     |   Readable Writeable Executable file - most programs are this

You use the same process to determine the number representing the permissions for the group that owns the file (y) and for the rest of the world (z). It's typically a bad idea to chmod 777 any file, as it allows the world to replace the program with whatever they'd like.

Note that root can mess with files however they darn well please. When root uses chmod on a file, the ownerships do not change, but the permissions are changed. If you want to keep a user from accessing a file that they own, you must change the ownership to root (or anyone else, for that matter). You can change ownership using chown.

Setting execute for a directory allows that directory to be read. That is, you can see what's in it.


chown is a lot simpler than chmod. You simply do chown new-owner. filename.foo as root and "new-owner" now owns the file and the file's group is set to new-owner's group. If you'd rather keep the group ownership the same, drop off the "." after "new-owner". You can change only group ownership with this, too: chown new-owner.new-group filename.foo. To just change the group ownership do chown .new-group filename.foo and it will leave the user ownership alone, while changing the group ownership.

Security Considerations

Be careful. Don't give the world write access to anything executable and just generally think before you do. Neither I, the Guide, or anybody else takes responsibility if for some reason this document messes things up, either by my stupidity, your stupidity, or freak accident. Those italics are to emphasize that you should be careful to avoid stupid mistakes with chmod - it can and probably will create some small security holes, especially if misused or used carelessly. So be cautious. End of security ramble.

Copyright (c)1998 jbm (jbm@intertek.net). All rights reserved. Permission to use, distribute, and copy this document is hereby granted. You may modify this document as long as credit to me is given.

   Page 1 of 1