Important Security Question

ruud · 2008-03-22 15:19:25

If you solve this some other way, might be a good idea to document it here, so others can use that information as well.

els · 2008-03-22 17:07:41

ruud wrote:

If you solve this some other way, might be a good idea to document it here, so others can use that information as well.

Yes, please! I’m in the same situation with one or two hosts.

redbot · 2008-03-22 20:09:28

Ruud, Els,
Well, sorry all, I spoke too soon, the fact is that I thought I was the only one with this problem (or potential problem) and I didn’t want to monopolize this thread and your patience, given my incompetence with everything server-related.
Anyway I came to the conclusion that the problem is exactly the one pointed out by ruud: the “images” and “files” directories are owned by my own username, while the image files are owned by the webserver (in my case “nobody”).
Ruud suggests to use FTP but frankly – once again – what you mean?
And regarding SSH login I barely understand the acronym …I feel so thick

ruud · 2008-03-22 21:59:25

If you’re willing to learn and have questions on a subject as important as security… don’t worry about our patience. It’s more than worth spending time to explain :)

Since cpanel didn’t let you see who owned the files and directories, I suggested using an FTP client or to log in using SSH (=Secure Shell, the secure followup to telnet). It would enable you to see the file ownership and permissions, as shown in the opening post of this topic.

I can think of three different hosting setups, when looking just at the username used when executing PHP scripts (like textpattern) and the username used by the webserver to serve static files (like images).

Let’s assume a user account named ruud, which you use for logging in (for example when uploading files through FTP). And if the webserver itself runs under a different username, let’s assume that’s www-data.

Note that the following is important mostly for shared hosting environments. If you’re on a dedicated server or on a VPS (virtual private server) where your files are completely shielded/separated from other users hosting other domains, then this doesn’t apply to you.

1. scripts and files both executed/served by username ruud

Probably not a very common setup in shared hosting environments. It’s safe because you can set permissions that allow nobody else to even read, let alone write/delete/create your files.

In this case, having 700 permissions would suffice for the directory, because everything concerning these files in that directory (creating them, reading them) is done by the same user, so only the user who owns the directories/files needs permission. The 7 means that the user who owns the directory can do anything with it: execute (1) + write (2) + read (4) = 7. You need execute permission on a directory to access anything in it.
The actual files in the directory could have 600 permissions, because the images are not programs and need not be executed. You just have to be able to create/write (2) them and read (4) them: 2+4=6.

2. scripts are executed as ruud, but static files are read by the www-data.

I think this is quite common when you’re in a shared hosting environment. It’s safe because while others on the server may be able to read some of your static files, you can set permissions more strict for your scripts (disallowing all access) and others cannot alter your files or create new ones.

Since all the writing/creating (2) of files happens with the same user name ruud, you need only write permission for the file owner. But reading (4) the files must be enabled not just for the user (ruud) himself, but also for the webserver (www-data):

user: 2+4 = 6
webserver: 4

So the files themselves need 644 permissions.
The PHP files need only 600 permissions, because they are started by the user ruud, not www-data.

The directory containing the files needs at execute permission (1) for both the user and the webserver. Only the user needs permission to write (2) new files or delete them. And if there’s a need to read the contents of the directory, then read (4) permission is needed as well.
Therefore the directory needs 711 or 755 permissions.

3. scripts and static files are both served under the webserver name ‘www-date’ for all hosted domains

If that’s how it works at your webhost. Don’t just consider switching, but run like hell to a webhost that knows what it’s doing. This is terribly insecure.

When both scripts and static files can be served by the same user (www-data) that can also access all the files on all the other domains on that same shared webserver, scripts from another domain on that server can read/write to directories that contain files for your domain, changing your stuff, installing malware, trojans and things like that.

Since you’re still uploading textpattern files to that server under your own user name ‘ruud’, the webserver can’t access it, because it runs onder a different username. Both for scripts and static files. So you have to grant permission to enable www-data to read/write files and directories owned by ‘ruud’, which means 777 for directories and 666 for files for this setup to work.

This is why a requirement to set 777 permissions should ring the alarm bells if you’re concerned about security.

Last edited by ruud (2008-03-22 22:01:58)

redbot · 2008-03-24 00:08:23

Thanks ruud! As always your explanations are very clear and exhaustive.
I just need some time to study it well now. I’m sure it will be very useful (not only) for me.

masa · 2008-03-24 01:14:42

ruud wrote:

You need at least execute permission on a parent directory to be able to access the child directory, so if the parent is set to 700, then only the owner of that directory can access the parent directory…. but if that’s true, then it’s pointless to make set the child directory to 777.

Ruud, if I understand your statement correctly everything should be fine as long as the web root directory is set to 755, meaning a child’s permissions can’t override the parent’s?!

The reason I’m asking is on Textdrive the settings are…

web root 755
images, files 755

but on another host they are…

web root 755
images, files 777

If I set images & files to 755 in the latter case, Txp diagnostics complains about them not being writable.

redbot · 2008-03-24 02:22:53

masa wrote

but on another host they are…
web root 755
images, files 777

masa, ruud
this is exactly my situation, plus all files are cmodded 644 and all directories inside the web root (except “images” and “files”) are 755.

Last edited by redbot (2008-03-24 02:51:23)

masa · 2008-03-24 02:39:47

redbot wrote:

masa, ruud
this is exactly my situation, plus all files are cmodded 644

Same here – is that save or not?

ruud · 2008-03-24 12:50:40

Files with 644 permissions and for 755 for directories is okay.
But needing 777 permissions for the directories to make them writable, that is definitely NOT okay. If that’s on a shared webhost, consult the tech support and ask them if it’s safe to set permission to 777.

masa · 2008-03-24 13:24:14

Ruud,

I understand that. Rather my question was, if the parent is set to 755 does setting a child to 777 override the privileges of the parent?

From what you said earlier…

…so if the parent is set to 700, then only the owner of that directory can access the parent directory…. but if that’s true, then it’s pointless to make set the child directory to 777.

…it sounded like it wouldn’t have any effect?!

ruud · 2008-03-24 14:27:04

A 777 child directory inside a 755 parent directory would work, but as I said before: please assume that 777 is not safe unless your webhost explicitly approves it.

rloaderro · 2008-03-24 14:33:44

Since, no one has mentioned it before – what about 775? Not as safe as 755, not as vulnerable as 777? Anyway it was as secure as I was able to go on a shared host since 755 didn’t work…

Textpattern CMS

Textpattern CMS support forum

#13 2008-03-22 15:19:25

Re: Important Security Question

#14 2008-03-22 17:07:41

Re: Important Security Question

#15 2008-03-22 20:09:28

Re: Important Security Question

#16 2008-03-22 21:59:25

Re: Important Security Question

1. scripts and files both executed/served by username ruud

2. scripts are executed as ruud, but static files are read by the www-data.

3. scripts and static files are both served under the webserver name ‘www-date’ for all hosted domains

#17 2008-03-24 00:08:23

Re: Important Security Question

#18 2008-03-24 01:14:42

Re: Important Security Question

#19 2008-03-24 02:22:53

Re: Important Security Question

#20 2008-03-24 02:39:47

Re: Important Security Question

#21 2008-03-24 12:50:40

Re: Important Security Question

#22 2008-03-24 13:24:14

Re: Important Security Question

#23 2008-03-24 14:27:04

Re: Important Security Question

#24 2008-03-24 14:33:44

Re: Important Security Question

Board footer