Get it right with *n*x perms

Too often I meet teams that fulfill installation instructions and still fight to troubleshoot issues, which turn to be just a permissions problem. Well, the real problem is that people often just execute instructions and treat the commands like black magic.

So after explaining this permissions thing over and over in many different places - I decided to share my way of explaining it here. The whole thing comes in 5 simplified concepts. No big deal. But if you put it this way - it does not take long to explain, and your target user is most likely to get it ☺

Sure, there’s more depth and edge-cases, but that’s not what people need to understand to get the mechanism and go on with their work.

Here is how I put it - enjoy.

1 - The Layers

Linux/unix systems manage permissions in 3 layers. Whenever a user access a file – the fate of the operation falls through 3 layers that may give the user a chance to access the file. If a layer denies – it moves to the next. If the last layer is checked and no grant is found – the access is denied.

The layers are:

  1. permissions to file owner
  2. permissions to associated user-group
  3. permissions to the rest of the users.

2 - The Permissions

Every layer can provide directives of 3 permission types:

  • read – the user may read the file
  • write - the user may change the file or delete it
  • execute - the user may invoke the file like a command, and the OS will automatically try to find what runtime it should be run with and execute the file on the user’s behalf.

Please note that the execute perm is a mere level of shortcut to automation concerning files which are also programs. It concerns just the process of resolving the run-time that the code-file contains instructions for, and passing the file-content to the runtime for execution.

The thing to note here is that a user with read perm from any of the levels may still be able to execute a program by calling the runtime and passing it the content of the program file - which they can alredy read (e.g python <path to py file> or sh <path to sh file>).

For text-files, the process of resolving the runtime is done with a concept called shebang - which is a text line in the first line of the file. Binary files (aka non-text files) are expected to be a program compiled to machine code - these zeros and ones that computers execute best (like ls, or like the actual runtime from the previous option).

3 - Representation - Perms Expressed as binary bits

3 layers x 3 permissions = 9 bits that control the files permissions – a.k.a mode.

Every bit is either on or off, and when represented in binary base – it’s basically a 3 digit binary number, 000 to 111 ☺.

A 3 digit binary number is basically a single digit of 0 to 7 (aka represented in octal base).

With 0 being 000 - no for all three, and 7 being 111 - being yes for all three - and for example, 5 is 101, which basically means read=Y, write=N, execute=Y.

3 layers is 3 layer descriptors, each is a single octal digit. As simple as that ☺.

Common layer descriptors are:

  • 7 - i.e. 111 - this layer permits everything
  • 4 - i.e 100 - this layer permits only read
  • 5 - i.e 101 - this layer permits read and execute, but not write
  • 6 - i.e 110 - this layer permits read and write, but not execute
  • 0 - i.e 000 - this layer does not permit a thing.

Expressing 3 layers with 3 octal digits, for examples:

  • mode 744 means - owner can do everytning, and everybody esle can only read.
  • mode 754 means - owner can do everytning, user-group may read and execute, and and everybody esle can only read.

Note 1: Don’t take for granted the 7 for owner - Sometimes owner will turn off the execution bits for himself to prevent the file from being executed by mistake (by giving up the automatic resolve of runtime). Or turn off the write bit for himself to mark the file write-protected.

Note 2: If a layer does not permit - layers after it may still allow. This means that 007 is effectively the same as 777!

4 - View – how do I see it?

When you run ls -la for given directory, every file entry is prefixed with 10 characters, after which there’s a number irrelevant to this discussion, but after it – the name of the owner, and the name of the user-group. Yes, same owner and usergroup referred in previous stages.

These 10 characters are basically the 9 flags discussed in concept 3, prefixed with one more flag that tells the OS if the record is a file or a directory. While directories are basically files listing the directory content - they do get a special treatment on the OS level.

The special treatment is that directories are binary files, and as such require Execute permission in order to look inside (e.g cd, ls, du, tree, ect…)

These 10 characters are a visual representation of the permission bits. The rule is that if the character is a dash (-) – it’s a No. Any other character is a Yes, where the character itself only helps us remember what bit it represents:

  • d = directory (only the first, and the first will always be (d) or (-))
  • r = read (the 2nd, the 5th and the 8th will always be (r) or (-))
  • w = write (the 3rd , the 6th and the 9th will always be (w) or (-))
  • x = execute (the 4th , the 7th and the 10th will always be (x) or (-))

Note there are more types, but the most common & important ones are there.

So, for example - a 10 char prefix of -rwxr-xr-- means a file in mode 754. i.e:

  • (bit #1 -> -rwxr-xr–) Not a directory
  • Owner user perms
    • (bit #2 -> -rwxr-xr–) Can read
    • (bit #3 -> -rwxr-xr–) Can write
    • (bit #4 -> -rwxr-xr–) Can execute
  • User-Group perms
    • (bit #5 -> -rwxr-xr–) Can read
    • (bit #6 -> -rwxr-xr–) CANNOT write
    • (bit #7 -> -rwxr-xr–) CAN execute
  • All other users
    • (bit #8 -> -rwxr-xr–) Can read
    • (bit #9 -> -rwxr-xr--) CANNOT write
    • (bit #10 -> -rwxr-xr--) CANNOT execute

NOTE: ls stands for list, -la means work with two switches:l and a, where l = show long format, and a = show all files.

Control

The first bit won’t change. Once an object is created - it will stay what it is, a file or a directory. This bit is informative only.

The last 9 permission bits – aka – file mode - is modified by the chmod, which stands for change mode.

syntax: chmod <bitmask> <path> e.g. chmod 744 notes.mc.

The number it accepts is the octal form of the binary bit-mask explained eariler. It basically means that instead of typing 9 charcters, you type 3 numbers, each one encodes binarically 3 characters - which fits well with the less key strokes idiom. No surprises here:

  • First digit controls r/w/x of the owner
  • Second digit controls r/w/x of the grouo
  • Last digit controls r/w/x of all other users in the system.

The owner-user and the user-group are the fields that are modified by chown – which stands for change ownership

  • syntax: chown <user>:<usergroup> <path>
  • e.g. chown appuser:app bin/www.

In both commands, the path accepts path wild-chards (? and *)

Q: Why so many short forms? Why encoded in octal? Why commands cannot be just list all files ?
A: To understand that one must understand the earlier days of computers. Now think for a moment how frustrated one gets today when dealing with a remote-desktop interface, where the visual interface lags. Heck - I see people lose their minds when their phone hicks-up, let alone not smooth enough. Now take that frustration to the days where computers were not that fast by themselves, not to mention the factor of the network itself which rode on analogue lines, and add to that the stress of a “computer technichian” working on a high-stake system like a national defense system, or a bank.

In days where responsivity of computers was slow, and every keystroak mattered - interfaces had to make the most of every key-stroke. It’s like why young people often prefer to express themselves with imogies. Less key stroaks, more meaning - if you know the language… So in the end of the day the short forms became the formal lanaguage, and since everybody adopted that language - it’s hard to see how it will be replaced, especially when you can find even today remote connections where every key stroak matters. Plus - it has that geeky coolness of I now know what the cool guys know.

So every time you use these shortcuts you reenact the first days, you’re connecting with the source - with the earlier days of computers. You remember where we came from, and should hold gratitude for where we’re at and where we’re going to.

Conclusion

Yes, a little cryptic, but it has its beauty. Once you understand how it works and how to use it - it’s not a black magic after all.

Further reading:

This obviously is a simplified version with the basics. To dig deeper - check these out:

Software Architect and node.js Expert

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com