Is it possible to execute a script if there is no permission to read it? In root mode, I made a script and I want the other user to execute this script but not read it. I did chmod to forbid read and write but allow execute, however in user mode, I saw the message that says: permission denied.


The issue is that the script is not what is running, but the interpreter (bash, perl, python, etc.). And the interpreter needs to read the script. This is different from a "regular" program, like ls, in that the program is loaded directly into the kernel, as the interpreter would. Since the kernel itself is reading program file, it doesn't need to worry about read access. The interpreter needs to read the script file, as a normal file would need to be read.

| improve this answer | |
  • 2
    Yes but in his case is there a solution? – Olivier Pons Mar 22 '12 at 10:53
  • 15
    One possibility would be to have a simple C program that embeds the script and calls the interpreter explicitly. A C program does not need to have read permissions to execute. – Arcege Mar 22 '12 at 12:04
  • 2
    Strictly speaking, the kernel does not discriminate in this case and it will in fact run the shell (the same way as if the executable file was a binary). However, the shell itself will immediately crash because it can't read the input file (the script file content). – knaperek Mar 21 '19 at 15:58

This is possible only for binaries.

$ chown foo:foo bar
$ chmod 701 bar

As the unprivileged user:

$ ls -lha bar
-rwx-----x 1 foo foo 7.0K 2012-03-15 03:06 bar

$ cat bar
cat: bar: Permission denied

$ ./bar

Now, here is the kicker. While the file is unreadable by conventional means, you can't actually prevent reading the file. This is actually a challenge on http://smashthestack.org/ (level 13). There is a well known utility called hktrace that allows you to read the file using ptrace.

| improve this answer | |
  • Very interesting (hktrace). – fthinker Mar 16 '12 at 5:01
  • 1
    is it possible to convert shell script to binary format? – ashim Apr 4 '12 at 22:57
  • 5
    Actually, you can prevent it, I think. Current linux kernel versions set the process to non-dumpable, meaning no normal user can ptrace it anymore, if the user is not allowed to read the binary. – thejh May 15 '14 at 11:49

This is not possible, at least on Linux (other Unices might allow it); think about it, when you run the script, the shell needs to read it in order to know what to do.

| improve this answer | |
  • 3
    It certainly is possible; OpenBSD allows any script to be executed without read permission. Under the hood it does this by creating a duplicate file descriptor for the interpreter to use. – eradman Apr 12 '18 at 12:36
  • @eradman I've put that (together with an example, explanation, and some remarks of mine) into an answer. – mosvy Oct 15 '19 at 7:03

There's a half truth to the previous statements. You can setup a script so that it's not readable by the user, but still executable. The process is a little drawn out, but it's doable by making an exception in /etc/sudoer so that the user can run the script as yourself temporarily without being prompted for a password. This method: - gets around the setuid patch for other distros. - allows you to give elevated permissions temporarily for a specific script without giving the user sudo rights to everything.

Follow the instruction on this post: File permission execute only

| improve this answer | |

You can, I think, do this with setuid.

Except that you can't because most distros (apparently) have setuid disabled because it's a massive security hole. It's disabled on mine, so I don't actually know that this answer will work, I'm posting it anyway because I think it should.

Anyway, if I wanted to do what you wanted to do--and I had a distro with setuid enabled for scripts--I would do something like:

$ chmod 700 myscript
$ cat > myscript-nonroot
bash myscript
$ sudo chown root:root myscript-nonroot
$ sudo chmod 4755 myscript-nonroot # make SURE this isn't world-writable!

Which is to say I would write another script whose sole purpose is to call the root-read-only script, change it to be owned by root, and give it the setuid permission. (Along with attendant non-writable status by everyone else.)

Since the myscript-nonroot function is readable by everyone it can be read and executed, and by the time you get two the line where you actually execute your script (bash myscript) it is being run as root (or whoever else you want, the exact user doesn't matter, as long as the wrapper file is owned by the same user.)

| improve this answer | |
  • What does 4755 mean? I'm new to this, so I would like to know what it means. I understand the 755 part. Thanks – Kevdog777 Jul 18 '12 at 8:17
  • 2
    the 4 sets the setuid bit. See the Modes section in the chmod man page on manpagez. – quodlibetor Jul 18 '12 at 21:16
  • Ok, I still don't quite understand, but it did take me a while to understand the 755 bit. – Kevdog777 Jul 19 '12 at 7:16
  • yep, actually chmod 755 is same than 0775 octal. there's a lot of confusion around that.. This page (manpagez.com/man/1/chmod) has an awfull and unneded horizontal scroll that i can't understand... – m3nda Apr 22 '17 at 5:41
  • setuid isn't disabled on any modern major Linux distro (or any modern major Linux distro that was active 8 years ago when this answer was written either); it's disabled for scripts only on modern kernels, but programs like sudo, su, etc. wouldn't work without setuid. – Charles Duffy Sep 30 at 18:20

On this situation I used sudo with a NOPASSWD option so the users can run the script without being able to read it.

| improve this answer | |

It works on OpenBSD

As already mentioned in a comment by @eradman, this is possible on OpenBSD.

As root:

hzy# cat <<'EOT' >/tmp/foo; chmod 001 /tmp/foo
#! /bin/sh
: this is secret
echo done

As a regular user:

hzy$ cat /tmp/foo
cat: /tmp/foo: Permission denied
hzy$ /tmp/foo

That works by passing /dev/fd/3 (or whatever the open fd to the script is) to the interpreter. That trick would not work on Linux, where /dev/fd/N are not special character devices which return a dup(2) of the fd when opened, but "magic" symlinks to the original file/dentry, which open the file from scratch [1]. It could be implemented in Free/NetBSD or Solaris ...

But it's not what it's cracked up to be

Basically giving the x (execute) permission means also giving the r (read) permission on any file which has a shebang [2]:

hzy$ cat /tmp/foo
cat: /tmp/foo: Permission denied
hzy$ ktrace -ti /tmp/foo
hzy$ kdump | tail -n8
 70154 sh       GIO   fd 10 read 38 bytes
       "#! /bin/sh
        : this is secret
        echo done
 70154 sh       GIO   fd 1 wrote 5 bytes

ktrace is not the only way; if the interpreter is dynamically linked executable like perl or python, a LD_PRELOADed hack which overrides the read(2) function could be used instead.

And no, making it setuid will not prevent a regular user from seeing its content; she could simply run it under ptrace(2), which will cause the setuid bits to be ignored:

As root:

hzyS# cat <<'EOT' >/tmp/bar; chmod 4001 /tmp/bar
#! /bin/sh
: this is secret

As a regular user:

hzyS$ ktrace -ti /tmp/bar
uid=1001(duns) euid=0(root) gid=1001(duns) groups=1001(duns)
hzyS$ kdump
    ... nothing, the kernel disabled the ktrace ...
hzyS$ cc -Wall -xc - -o pt <<'EOT'
#include <unistd.h>
#include <sys/types.h>
#include <sys/ptrace.h>
#include <sys/wait.h>
#include <signal.h>

int main(int ac, char **av){
        int s; pid_t pid;
        if((pid = fork()) == 0){
                ptrace(PT_TRACE_ME, 0, 0, 0);
                execvp(av[1], av + 1);
        while(wait(&s) > 0 && WIFSTOPPED(s)){
                s = WSTOPSIG(s);
                ptrace(PT_CONTINUE, pid, (caddr_t)1, s == SIGTRAP ? 0 : s);
hzyS$ ./pt ktrace -ti /tmp/bar
uid=1001(duns) gid=1001(duns) groups=1001(duns)
hzyS$ kdump | tail -5
 29543 sh       GIO   fd 10 read 31 bytes
       "#! /bin/sh
        : this is secret

(sorry if this is not the most straighforward way to demonstrate it)

[1] this could be emulated on Linux by using binfmt_misc, but the interpreter will have to be modified, or a wrapper will have to be used; see the last part of this answer for an example deliberately made ridiculously insecure.

[2] or in general, any file which will not cause execve() to return ENOEXEC.

| improve this answer | |

Yes, if you are root user, you can execute file without read permission

# echo "echo hello" > test
# chmod 100 test
# ll test
---x------ 1 root root 10 Nov 29 12:13 test
# ./test

But if you log in with any other user, you cannot execute this file

$ ./test
-bash: ./test: Permission denied
| improve this answer | |
  • 3
    This doesn't really answer the question, cause root can still read the file even without permission. – wjandrea Mar 22 '18 at 20:12

To make your scripts unreadable yet executable, you have 3 major options:

First Option

Use the openssl command to manually encrypt it. And in the future, when you want to run the script, you'll have to run openssl manually again, and provide the password to decrypt.

Encryption with openssl:

cat yourscript.sh | openssl aes-128-cbc -a -salt -k yourpassword > yourscript.enc

Decryption with openssl:

cat yourscript.enc | openssl aes-128-cbc -a -d -salt -k yourpassword > yourscript.dec

yourscript.dec will be the same as your original script yourscript.sh

Second Option

Use a site like www.Enscryption.com to automatically encrypt your script and make the encrypted version of the script executable. This site uses both the encryption capabilities of openssl and some other obfuscation methods to make it quite difficult for intruders to pry into your script or to unveil secrets you want hidden. With this site, you can encrypt shell scripts and command line perl, python, ruby scripts. I think php as well.

Third Option

Use a tool such as shc. Looks like it hasn't been updated since 2012. but I have used it in the past. You have to compile your script for each OS on which you wish to use it on, if the OS is different from the one you used to compile it.


If hiding your code is of great importance to you, relying only on permissions and ownership is going to help you, as anyone with root can get to it. That's just a fact. What you can do, if you really want to do prevent unauthorized viewing of your code by anyone is to write a script around the openssl command. Make it so that, before the script runs, it'll prompt for a password AND after password is given, it'll run the script without writing it to a temp file. If this sounds like too much work then options 2 and 3 should be sufficient for your purposes.

| improve this answer | |
  • The "shc" link also points to the one page from before. Are you by any chance affiliated with this page/service? – phk Jun 8 '16 at 22:12
  • 3
    If you cipher your script it will not be able to run without key. If you sent the key to a user to run it, will be able to see it's content. This anwers is so stupid... – m3nda Apr 22 '17 at 6:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.