chmod 1,2 and 4, what exactly do they do?

Question

I was wondering about having only read, only write, or only execute permission, and what it means.

If I have write permission only, does that mean I can append to, or replace the contents of the file, but not read the current contents?

Even more confusing: If I have read only, why can't I just copy the file and execute it then? Is there a reason that read permission doesn't automatically grant execute permission? What's the use of not giving someone execute permission, if they can just copy paste the file somewhere else and execute it there?

And if they have only execute permission, what does that mean then? Doesn't executing a file require you to see it?

And my last question: Where does it make a difference if execute permission is given? executing a .txt file doesn't make sense. On Windows there are for example .exes, .bats, and so on. On Unix systems, I only know of .sh. Is there a certain number of extensions that define executable files? If now, how can I spot one?

Answer 1

In UNIX chmod 1 = execute, read is 4 and write is 2.

Anything can be chmod'ed 1 and then the current shell will try to run it, you can type its name as a command. There's some file "magic" at the start of the file, if the first couple characters are "#!" (the shebang) then the next part of the line lists the path to real executable to run and any options to pass to the shell. The text script is passed to that executable binary to read the file and effectively run it.

You asked, doesn't execute require reading, well yes, but that's going to be at the discretion of the binary program, e.g. korn shell, to show you the file. Generally it's like DRM, it's respected by the programs to check your permissions against the file. I've setup routines in shell scripts and marked them --x executable only and it could be run and basically not read (I think some older UNIX versions had trouble with this, just like special directory sticky permissions on /tmp, but that's another topic).

If a script is only marked 4, or "read", it grants you permission to cat the file out to your terminal. Yes you could execute it depending on how you passed the lines to a shell interpreter, many shells have a command line option to tell it to read lines from a given file and run them as if it were a script.

And for you last case, chmod 2 is write permission. If you grant only that then you can only append or destroy the contents of the file. You can't destroy/unlink/remove the file based on the file's permissions, the line that controls if the file exists or not is inside the directory (which I like to think of as a file too).

I'd have to argue chmod 2 isn't very useful on a file, but on a directory you can make a sort of safe "drop box" for other people to send you files, generally students in a class, and you hope they don't overwrite the filenames of other students.

There's should be some help in the manual pages "man chmod", and hopefully you have your own UNIX like system to try things out on in your own home directory. A lot of the weirder cases like execute only really require another userid or friend to show you outcome of the various permissions.

Answer 2

What it means

The security permission octal values allow the correlated permissions to be set explicitly on an object. You can get explicit with these permissions you set on an object with chmod. See the below referenced table for more detail regarding this as well.

---

What I have

For example, if you want to allow someone to execute a file to run some logic and per the Shebang without being able to read the content or see the logic, then that flexibility is there.

---

Set per your own need

You set the security permissions as per your own individual needs accordingly so if some security configuration does not make sense for you, then you simply don't need to use it as such.

---

Numerical Permissions

The chmod numerical format accepts up to four octal digits. The three rightmost digits refer to permissions for the file owner, the group, and other users, respectively. The optional leading digit, when 4 digits are given, specifies the special setuid, setgid, and sticky flags.

Each digit of the three rightmost digits represent a binary value, which it's bits control the read, write and execute respectively, where 1 means allow and 0 means don't. This is similar to the octal notation, but represented in decimal numbers.

# Permission              rwx Binary
7 read, write and execute rwx 111
6 read and write          rw- 110
5 read and execute        r-x 101
4 read only               r-- 100
3 write and execute       -wx 011
2 write only              -w- 010
1 execute only            --x 001
0 none                    --- 000

For example, 754 would allow:

• read, write, and execute for the OWNER, as the binary value of 7 is 111, meaning all bits are on.

• read and execute for the GROUP, as the binary value of 5 is 101, meaning read and execute are on but write is off.

• read only for EVERYONE ELSE, as the binary value of 4 is 100, meaning that only read is on.

Answer 3

As noted by others, file permissions are a bit mask. The system does not go out of its way to prevent the use of strange or useless combinations: useless doesn't mean harmful.

If I have write permission only, does that mean I can append to, or replace the contents of the file, but not read the current contents?

Yes.

If I have read only, why can't I just copy the file and execute it then?

You can, with exceptions. Copying a "privileged" file (one which has setuid/setgid bits or Linux file capabilities) will not copy those properties. You also need a place to copy it to, and it's possible to have a system where the /home partition disallows executing files from it.

The same can be done without copying, by manually invoking the corresponding interpreter. For example, you can run shell scripts via sh /path/to/script even if they're not executable. Binaries on Linux also have an interpreter, /lib/ld-linux.so.

And if they have only execute permission, what does that mean then? Doesn't executing a file require you to see it?

It does – but this is checked after the setuid bit is processed. If you are executing a setuid program, it will have the owner's privileges, so only the owner needs +r.

For directories, +x has a different meaning (it allows you to traverse the folder, i.e. access items inside). If you know the exact name of a file inside, you can access it having just +x, not +r, on the directory.

Where does it make a difference if execute permission is given? executing a .txt file doesn't make sense. On Windows there are for example .exes, .bats, and so on. On Unix systems, I only know of .sh. Is there a certain number of extensions that define executable files?

Executability is not defined by the file name, but by its contents. (After all, you're executing the contents, not the name.)

A file can be executable when the kernel knows how to load it as one. The Linux kernel understands ELF binary files, as well as "script" files with the #! header as their first line. (Same for most other Unix-like operating systems.) So it makes sense to use +x on these two kinds of files only.

For example, if a script file begins with #!/bin/sh, then executing it does the same as manually running /bin/sh myscript.sh. The same can be applied to Python or Perl or Ruby or TCL or C# or Node/JavaScript or any other language. (Again, note that the filename's suffix has no relevance – only the magic header does.)

The advantage is that your system can have commands written in various different languages, and you can use them without having to care which interpreter each command uses.

Windows is in a similar situation. It also has the same 'executable' permission bit, and while the graphical interface wants the .exe suffix in filenames, the actual kernel only cares about the file's contents. (Windows uses MZ/PE binary executables and doesn't support #! for scripts.)