17

I have a php script which needs to connect to a database. The credentials for the database are stored in another php script.

If I set the permissions for the credentials file to 661 so that Public has execute permission but not read permission, does this allow the main script to access the credentials and connect to the DB while preventing someone with a user account on the server from viewing the contents of the credentials file?

I guess I'm confused as to the distinction between read and execute. Does a php script (running as www or something similar) need read-permission to include another php script and use any content inside? Or does it just need execute? Does read permission implicitly give execute permission?

Sub-Question: If I set all of my scripts to only have execute permission and not read, are there any pitfalls I should expect? This is assuming that I will leave any files I need explicit read permission (data files) set to read.

Anthony
  • 36,459
  • 25
  • 97
  • 163
  • I recently read about setuid and setgid bits. Would it be possible to use setuid on the php interpreter and give php interpreter and php files their own uid, and setting the script attributes only giving read permission to the user? Then the only way to read the php files is to be logged on as the php user, or via the interpreter by anybody. – RufusVS Mar 08 '19 at 16:11
  • I was too slow to edit my previous comment with this: setuid is dangerous. if you leave php as root user, an exploit would be to run php on one of your own scripts and it would have root access to your system,( as I understand it.) – RufusVS Mar 08 '19 at 16:23

2 Answers2

13

Scripts are read, not executed. Execute permission for scripts tells the loader or kernel to read the shebang line and pass the script to the named interpreter.

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
  • So if I have a script in a folder called "secrets" and have secrets set to execute-only, can someone who once had read-access to secrets (but now doesn't) plug a file name in directly to something like nano and still see the contents? This is my real concern, I guess. – Anthony Jan 06 '10 at 02:40
  • If "secrets" is a script then it can't be run if the user running the interpreter does not have read access to the script. Whatever permissions it used to have is irrelevant; the only time the permissions matter is when the file is opened, either for reading or for running. – Ignacio Vazquez-Abrams Jan 06 '10 at 02:42
11

As far as files are concerned, execute permission is irrelevant to you - the user account your web server is running under needs permission to access and read the files in question. In order to traverse into a directory, the user will also require execute permission on that directory.

If you are trying to make your scripts readable by the web server (let's say you're running as the account "www" which belongs to group "www"), and not by other users on the system, here's what I would do (assumes your account is "myuser"):

# Change owner to "myuser" and group to "www" for file(s) in question
chown myuser:www config.php

# 640: myuser has rw-, www has r--, world has ---
chmod 640 config.php

If you want to prevent the world from reading any file in a "secrets" directory, just disable the execute bit:

# 750: myuser has rwx, www has r-x, world has ---
chmod 750 secrets

If you set all your scripts to have execute permission but not read permission, nobody can do anything useful with them (including the webserver) ;-)

pix0r
  • 31,139
  • 18
  • 86
  • 102
  • Note that if other users have access to run their own PHP code thru the web server then this won't stop them. In that case maybe look at open_basedir or a solution that allows you to run different vhosts/apps as different users. – oops Jan 06 '10 at 02:53
  • Yeah, on closer inspection, I found that www was a member of the group for the directory I was basing my confusion on. I wasn't trying to hack it, I just wanted to emulate what they had done but without just mirroring it. – Anthony Jan 06 '10 at 03:31