20

What is the purpose of Linux permissions such as 111 or 333 (i.e. the user can execute, but cannot read the file), if the ability to execute does not automatically imply the ability to read?

hildred
  • 5,829
  • 3
  • 31
  • 43
trolley813
  • 303
  • 1
    Do you have an example for such a setting? I think you are right. You cannot execute what you can't read. These combinations are just theoretical in the space of permissions between 0000 and 0777. Note that the leading 0 should be added to show the octal base of the number. – ikrabbe Jul 06 '15 at 23:04
  • 7
    Unless it's a script (eg. shell-script) you actually don't need read-permission to execute a command. A "normal" executable -- eg. su, bash or vi -- just need the executable-bit to be set, to allow a user to run it. A file that can't be read, can't be copied. So by not allowing a user to copy a security-important command (like su), he's prevented from making his own copy of it -- and also from trying disassemble it. *BSD has several commands with execute but no read permission. – Baard Kopperud Jul 07 '15 at 10:26

3 Answers3

27

I played with it and apparently, exec permissions do not imply read permissions. Binaries can be executable without being readable:

$ echo 'int main(){ puts("hello world"); }' > hw.c
$ make hw
$ ./hw
hello world
$ chmod 111 hw
$ ./hw 
hello world
$ cat hw
/bin/cat: hw: Permission denied

I can't execute scripts though, unless they have both read and exec permission bits on:

$ cat > hw.sh
#!/bin/bash
echo hello world from bash
^D
$ chmod +x ./hw.sh
$ ./hw.sh 
hello world from bash
$ chmod 111 ./hw.sh
$ ./hw.sh
/bin/bash: ./hw.sh: Permission denied
Petr Skocik
  • 28,816
  • 4
    This is correct as the second example uses the #! to start as it misses the ELF-header and so requires the file to be readable for it to guess which executable to use it. This is a common situation for where you want to protect the contents of the files from being copied to other locations. A license manager is common example where you would see this. – hspaans Jul 06 '15 at 23:42
  • 2
    Note that you can still read an executable-only binary: http://unix.stackexchange.com/a/34294 – 小太郎 Jul 07 '15 at 12:23
  • I tried #!/bin/rm which only needs to read the first line, and the file can disappear. – user23013 Jul 07 '15 at 12:36
  • 8
    @hspaans: The shebang is handled by the kernel, and the kernel doesn't care about quaint little things like permissions. It's the shell (or interpreter) which needs read access. The kernel runs (say) /bin/bash hw.sh, and then bash tries to open hw.sh for reading (and fails). – Kevin Jul 07 '15 at 14:08
  • 1
    @user23013 You don't need read or write permissions to delete a file. You only need write permissions to the enclosing directory. – Petr Skocik Jul 07 '15 at 14:20
  • 2
    I for one very much hope that the kernel does care about permissions. Nothing else does. What the scary sentence in @Kevin's post means is that the kernel only requires execute permissions to execute files, irrespective of whether they use the shebang. – Emil Jeřábek Jul 07 '15 at 14:27
  • 4
    @EmilJeřábek The kernel cares about permissions when deciding what an application process can do. But since it's the component that implements the permissions, it can also ignore them internally. So it can read the shebang line when determining how to execute the an interpreted file, or read the contents of an execute-only binary file into memory. – Barmar Jul 08 '15 at 19:07
16

it make sense for directories, for example if you keep (secret) executables in a specific directory and then allow users call those files without being able to see the directory content (but knowing that a specific file is there after you informed them!). 333 compared to 111 allows writing/deleting files to/from those directories without being able to see the content of the directory.

Afsin Toparlak
  • 426
  • 6
    At my Uni, those permissions were used to drop assignments into a directory without students seeing either others work. The lecturer was old skool. –  Jul 06 '15 at 23:17
  • @DarkHeart Interesting. I hope you had to add a random component to the filenames, because otherwise, if that isn't an incentive to try and copy from your classmates, I don't know what is. – Petr Skocik Jul 07 '15 at 11:23
6

Obviously not all combinations are that useful, but to take the one you mentioned specifically... You actually don't need read permission to execute a file -- only execute permission -- unless the file in question is a script (e.g. a shell-script (.sh), perl-script (.pl) and so on). Normal binaries can be executed with just the execute permission. On *BSD-systmes, several executables gives execute permission without read permisson, especially on "security-important" commands -- e.g. su.

So why not give users read-permission (and just execute-permisson)? Becuase a file that can't be read by a user, can't be copied by that user either! Removing the read permission, prevents users from making their own "personal" copies of executables -- which they later may be able to abuse (e.g. get SUID=root on).

And not having write-permission, prevents a file from being accedently deleted.

Mind you, not giving neither read-nor write-permission to the owner is a bit uncommon, but sometimes it may be a good idea to prevent even the owner from just deleting a file. Of course the owner -- not to mention root -- may always circumvent such measures, if not in other ways, then simply by chmod the permission on the file.

0x6773
  • 115
Baard Kopperud
  • 7,153
  • "it may be a good idea to prevent even the owner from just deleting a file." — except that you do not need any kind of permission on a file (read, write, or execute) in order to delete it. – Celada Jul 20 '15 at 19:32
  • Ready-only executables can be used for example if the executable embeds a database password which it uses when run to connect to a database and do its job but it does not necessarily want to reveal the password. – Celada Jul 20 '15 at 19:33
  • @Celada, it's an old question, but wouldn't such be an approach be susceptible to memory dumping through looking up the memory region offsets in /proc/${PID}/maps and then reading the relevant sections of memory from /proc/${PID}/mem? Or does restricting the permissions on the executable's file also restrict read permissions on its relevant sections in memory during execution? (The latter seems unlikely, IMO.) – Spencer D Oct 26 '19 at 03:07