About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Home » Learning Curve

Files, Ownership, Permissions, Stuff Like That

It's really simple. Really it is.


Buy It

Try It

Right now the focus on Apple is all about the iPad but believe it or not but there are still a lot of people switching over to Apple computers. Most of these switchers are coming from the (gasp) Windows platform. And many of them are bewildered at the supposed complexity of OS X. Files have owners? Permissions? O RLY? What's that?

Opening an Apple laptop and looking at a file system with over 100,000 files and 20,000 directories - that can seem daunting. Windows can have a lot of files - but nothing like that! And Windows won't ever have 20,000+ directories. WTF?

Appearances deceive. Really they do. The hallmark of a Unix system - and Apple's OS is a Unix system - is (get ready) simplicity.

Simplicity is a trademark of Ken Thompson, the main creator of Unix. If there's anything Ken represents, it's simplicity. (That and being cryptic of course.) Unix doesn't interact unnecessarily with the user. You're never going to get a prompt out of the blue asking you 'where would you like to go today?' You do things - and if things turn out OK, you don't get a message of the type 'OPERATION SUCCESSFUL!!1!' You just get no message at all. In Unix, no news is always good news.

Being cryptic is a trademark of Ken Thompson. Ken was once asked if he'd change anything in the Unix he created and he famously quipped 'I'd change the creat() API to create()'. Yes, he famously truncated the final letter in the word 'create' when naming the Unix API for creating files. Why? Because he's cryptic.

Cryptic can be a good thing. You type 'cp' instead of 'copy', you type 'mv' instead of 'move', and 'rm' instead of 'remove'. Over time you save a LOT of typing. That's efficiency. It may take a day or two to remember that 'mv' stands for 'move' but once you learn it - as you learn to drive a car - then you got it. And you can kiss all those extra letters goodbye forever.

Simplicity is more of a hallmark than cryptic. Ken understood intuitively that only a simple system could be powerful and adequately maintained - and indirectly only a simple system can be securable. Unix isn't a hodgepodge like Windows - it has security built in from the foundation. That security is in file ownership and permissions.

ugo

Dave Cutler's NT Server has access control. That's the whole idea. Some of that won't have to be mandatory. It's possible but not necessary under all circumstances. Unix has mandatory access control: this means that every file system object has some sort of scheme for determining who can do what with it. You can theoretically open your files to the entire world, but this will never happen by default. Simply saving a new file to disk will imprint access control on it. You can't get away from it.

How does it work? Again, the key is simplicity. Ken understood that file access has to ultimately be divided up into what the creator of a file can do, what the creator's 'friends' will be able to do, and what (if anything) everybody else will be able to do.

In Unix parlance these three entities are known as user, group, other and often referred to as u, g, o for short.

user - the creator of a file. It's only the user who can set the permissions for a file. The user can grant or deny ways of accessing the file for everyone else. And the user is the only one who can change these permissions later on.

group - a group of users associated with the file. All Unix users belong to one or more user groups. These groups imply different generic levels of privileges. The user can set and reset the group associated with a file and the user directly decides what members of this group will be allowed to do with the file.

other - everyone else. Not the user/creator and not anyone in the file's group. The rest of the users on the system. It's quite common to find that these 'others' have no rights whatsoever with files. It's also common to find the 'others' cannot modify the files - in fact it's considered really bad to let a file be 'world writable'. That's asking for trouble.

Permissions are also very simple. There are only three permissions associated with a file: Read, Write, and eXecute, normally abbreviated to 'rwx'.

These three permissions are allotted for user, group, and other.

It's perfectly possible (but obviously not very practical) to create and save a file and then remove all permissions so you can't even read it back yourself. Do like this as an experiment: start a new text file (appropriately with TextEdit) and put a few lines of text in it, something like 'this is a file I soon won't be able to read', then save it to disk in your 'Documents' folder as unreadable.rtf. Close TextEdit, then open the file again and verify you can still read it (or even edit it).



Now drop to a command line (open Terminal.app) and issue the following command to navigate to the file. Don't worry about the syntax yet if it throws you.

$ cd ~/Documents                      # cd changes your directory

Now change the permissions (the 'mode') on the file with the following command.

$ chmod 000 unreadable.rtf            # chmod changes the 'mode' (permissions) of a file

Now try opening the file in TextEdit again.

The alert panel says you should contact your computer or network administrator for assistance but you won't have to do that. You'll just reset your file permissions again so you can get back into your own file. (It's really wrong of an OS vendor to assume users are so helpless and unskilled - most OS X users don't have an administrator anyway, do they?)

$ chmod 644 unreadable.rtf            # chmod changes the 'mode' (permissions) of a file

That should do it.

Permissions

So how do permissions work? Again: they're very simple. The permissions that blocked your access to the file were given as '000' - which makes sense as it seems to imply 'lots of nothing'. And that's what it was. The '644' is a bit more diffy. But with time you'll wonder why you ever hesitated to use such a system.

Unix file permissions are bit-wise and expressed in an octal radix. What does that mean? It means you're actually setting individual bits - binary digits - and that the numbers these bits represent can best be depicted using an octal numbering system.

There are only eight digits in the octal system - 0 through 7. Those first numbers are the same as they are in the decimal system. But there are no further digits - there is no '8' and there is no '9'. You have to scoot to the left to express an '8' or a '9'. 8 in octal is 10 - one 8 and zero 1s. Hard to grab? Then hold off on that a second and concentrate instead on the values for read, write, and execute.

Read - 4 | Write - 2 | eXecute - 1

Each of the three digits of a file's permissions represent permissions for user, group, and other. And fortuitously in that order as well. So '000' means 'zero permissions for the user, zero permissions for the group, and zero permissions for everyone else too'.

Likewise, '664' means (follow along with the table from above):

user6read (4) + write (2)
group4read (4)
other4read (4)

So a '644' on a file means you can read it and edit it (write to it) and everyone else, your group included, can only read the file. And that's convenient. So others can see your files if you want but they can't modify them.

You might also want to make your file more exclusive - remove read permissions for 'others'.

$ chmod 640 unreadable.rtf            # chmod changes the 'mode' (permissions) of a file

Or you might want to get really picky and close off everyone.

$ chmod 600 unreadable.rtf            # chmod changes the 'mode' (permissions) of a file

Ownership and permisssions:

  • Only the owner of a file can set its permissions.
  • Files have three possible permissions: Read, Write, eXecute.
  • Every file on your system has an owner and a group associated with it.
  • Every file has permissions set for them and for everyone else - no exceptions.

umask

Unix systems come with a default permissions set used when saving files. This is expressed through something known as the umask. The usual result of this 'umask' being used when saving files (it's done automatically beyond your control) is that your own files will be save with permissions '644'. Which is what unreadable.rtf most likely had from the beginning and what you later used to restore its permissions.

The eXecute Bit?

But what about the eXecute bit? Unix wasn't learned in a day. Take what you have now and sleep on it. You'll most likely find a new article dealing with the execute bit (and lots more) in the not too distant future.

See Also
Learning Curve: Files, Ownership, Permissions, Stuff Like That (2)

About | ACP | Buy | Forum | Industry Watch | Learning Curve | Search | Twitter | Xnews
Copyright © Rixstep. All rights reserved.