About | Industry Watch | Learning Curve | Products | Purchase | Search | Testimonials
Home » Learning Curve » A Gullible's Travels

~A Gullible's Travels~

Part Four in which Micro Luser Gullible installs burglar alarms.

Buy It

Try It

IV. Where You Can't Get In

'Keep it in ASCII.'
 - Unix programming guideline

You're trusted if your system administrator lets you roam outside your home directory; this isn't a given in all cases. And you trust others if you let them into your private area of the file system.

Microsoft Windows doesn't have concepts like this because Microsoft Windows is essentially still a standalone system. And with standalone systems nothing really matters. For if it did matter it would be lights out and game over by yesterday. Which coincidentally is what's happened to Windows over the years.

Microsoft have funky locations like 'Documents and Settings'. Gee is this where users are expected to put their own files? Really? Oh wow. Now what prevents other users from going in there and seeing what other people have on disk?

Oh wow.

And this 'Program Files' or whatever it's called in localisations: all program files for everyone are stored in the same location? Really? Oh geez. So how does one distinguish between a licensed user and a user that is not licensed?

Oh geez.

Where do you keep your program files on a Microsoft Windows disk?

Enough already. Time to look instead at how the other happier half live.

A Home is a Castle

Part I discussed how user accounts are set up on Unix; this part discusses how permissions are used to control who gets to do what with your files.

Permissions on Unix are actually a combination of ownership and permissions. The one is meaningless without the other. On Microsoft systems you find file attributes like 'read-only'. Read-only for who?

Precisely. Read-only for toute le monde - that's all a standalone system can accomplish anyway. Windows today has Cutler's ACLs but how many people know how to use them? And how many people actually bother? Not many.

Windows lacks a usable user-friendly effective way to control file access - period. And that's one of its most critical shortcomings. And Windows won't have this because the concepts of ownership and permissions coupled to ownership are not tied down and established at a low enough level in that latter-day MS-DOS standalone system.

Now over to Unix.

All file system objects - files, directories, and more - have settings for three basic means of access: reading, writing, and executing. And they have specific settings for these means of access for three basic user groups: 'user', 'group', and 'other'.

'User' is the person who creates an object. Creates a directory or a file. No ordinary user may ever change this basic ownership of a file. Unless an administrator gets involved the original owner of any object you create will stand - it will remain you.

'Group' is the group the object belongs to. This is automatically specified when you create any object based on what groups you belong to and which is considered your default group specified at login.

Groups are very simply user groups. These groups will necessarily by specification and through practice have different levels of accessibility. The group 'wheel' is considered the 'top drawer' group and generally membership is severely limited. Other common groups are 'staff' and 'admin'. And even for the latter of these two membership is limited.

Where Microsoft Windows has a single 'super power' account ('SYSTEM') that is never used by a real user and then nothing else save 'Administrators', Unix has any number of granular groups to assist in system administration and to make sure not too many people have privileges they don't need and shouldn't acquire.

Escalating to top level (the root account) is necessary for some operations but no one but a member of the admin group is generally allowed to jump like this. It wouldn't matter much if you had things you had to do but were only a lowly member of 'staff' - you'll have to get somebody else to help you. You won't be able to do it yourself.

'Other' is everybody else. Permissions that apply to 'other' apply essentially to everyone - including the owner and the designated group. 'Other' permissions are often by their very nature severely limited.


All Unix users are identified by a unique numerical user ID or UID. This can translate into a text representation at any time. All groups are identified in the same way - by a unique numerical group ID or GID.

By definition a user with UID 0 and GID 0 is root - the highest honcho in the land. 'Root' is an account that can do 'almost' everything. [More about this perhaps later.]

Note the name of the root account may be given as 'root' but it doesn't have to be. An account with UID 0 and GID 0 is root no matter the actual name.

[So yes this is a way hackers might try to install back doors on your system - so keep a lookout.]

Ordinary user accounts usually start with UID 501. [Yes this is a custom also found on Windows.]


Given three classifications for users with regard to file system objects - user, group, other - it's now possible to see how Unix file permissions are organised: they're set up in three groupings of 'read', 'write', 'execute' for each of the three user classifications. Masking one's entire home area so nobody else has any rights at all effectively keeps everyone out.

When read in literal form they're grouped with 'rwx' for - from the left - the user, then the group, then everyone else. The first character denotes something else: it can for example be a 'd' to denote the object is a directory.

The heading for this section denotes a directory where everyone has full rights.

It's important to realise 'executables' can't be 'executed' simply because they contain code that can be run (either ordinary 'relocatable' 'executables' or scripts). The 'x' bit must be specifically set for the current user.

Also it might not be obvious but for the record: only the 'user' (owner) of a file can change its permissions. If a file you want to read, write to, or execute is not available to you and if you don't own it then you're 'SOL'.

Directories are Files Too

Everything is a file on Unix. Ordinary files are often called 'regular files'; then there are of course directories. But there are other types as well. There are symbolic links, sockets, whiteouts, FIFOs or named pipes, character devices, and block devices. In addition to 'regular files' and directories.

An 'executable' bit on an ordinary file makes perfect sense: it means the system will allow you to run the file. Directories can have the 'x' bit as well; what does that bit mean with them? It means you can 'enter' them. Shell ops often presume a 'current working directory' and to this end there's a command similar to the Windows chdir called 'cd' which changes your current working directory.

Remove the 'x' bit on a directory and then try to 'cd' into it. It won't work.

$ mkdir X
$ chmod 0600 X
$ cd X
cd: X: Permission denied

You need read permission on a directory to list its contents; and you need write permission to change its contents. This doesn't imply you need write permission on a directory to change the contents of any of its objects - that pertains to each and every object directly. To understand what 'write' on a directory means you have to know what's inside Unix directories.

Again: directories are just files like any others. They're treated differently and have a different 'file type' (04 octal) but they're just streams of bytes like all the rest.

Unix directories contain essentially two things: file names and inodes. Inodes are indexes into the volume control block (commonly called the ilist). The entries in the ilist are commonly called iblocks.

The iblock for any given file contains all information about the file save one tidbit conspicuous in its absence: the file name itself. Unix files must be distinguished from file names: a physical file is linked to by a specific name found in a specific directory. Or two. Or three. Physical files can be represented by any number of volume paths.

The file system keeps track of how many links there are to each file. This is part of the information found in the iblock. Removing a file merely decrements its link count; storage for the physical file is not freed until the link count gets to zero.

  • You can have a situation where you can read and write to all the files in a directory but may not add new files, remove existing files, or rename existing files.
  • You can have a situation where you may not even read the files in a directory but you're able to remove (replace) them.
  • You can have a situation where you're able to run a program but you can't even look at it.
  • You can have a situation where you can place files in a directory but you can never see what you've put there.

And so forth.

Read on.

About | Industry Watch | Learning Curve | Products | Purchase | Search | Testimonials
Copyright © Rixstep. All rights reserved.