Viewing Thread:
"File permissions - help, please?"

Hi

As several others have noticed, files on the Freeola web servers, that are updated by php scripts, have had to have their Unix permissions changed. I've had to set mine to 777 to get some of my scripts working. But I thought that:

a) these numbers relate to owner/group/everyone
b) 7 is the most 'open' option
c) so 777 gives *everyone* full read/write/whatever access. This sounds pretty insecure to me.

Isnt the php script the 'owner'? I thought it was, so I'd only needed to give access to the owner previously. Freeola support tell me that I need to give access to 'group' and 'everyone', because of the upgrade, which has made my site 'more secure'. But it seems to me to be *less* secure, to give everyone full access.

I'm obviously not understanding something here. Can someone explain?

Thanks in advance ...

This would be known on certain other forums as karma whoring.. *cough* slashdot *cough*



From the chmod unix manpage:





A numeric mode is from one to four octal digits (0-7),

derived by adding up the bits with values 4, 2, and 1.

Any omitted digits are assumed to be leading zeros. The

first digit selects the set user ID (4) and set group ID

(2) and sticky (1) attributes. The second digit selects

permissions for the user who owns the file: read (4),

write (2), and execute (1); the third selects permissions

for other users in the file's group, with the same values;

and the fourth for other users not in the file's group,

with the same values.



If you have shell access you can use the more understandable "chmod uoga+rw" letter format, otherwise hope your ftp client is a bit friendlier..



-luke

Hi

This isnt really going to help, so much as agree with you. I've just set up a new file via a PHP script (with the "a+" option on the fopen), and it appears that the script will continue to add to the file quite happily. Mind you, I havent yet had a look at what the permissions are. But I also had the problems you're talking about with files that were on the server prior to the upgrade - their permissions had to be changed to 755 or more.

Hi. I posted this in another topic, but it did not get a response. If this is because I am not making sense, then please let me know and I'll try and be clearer. Here's the message:

"When I create a new file, the file permissions are set to the default 311. (This is what all the others that are used for my scripts are set to). Now I have already found out that I can't access my current 311 files anymore. Since the upgrade, I have had to set them to 777. But I _can_ access the new files I have created, despite the fact that they have the same file permissions as the ones I can't.

Can anybody help me out?"

Basically, I was pointing out that once your script creates files, they worked the same as they did before the upgrade. Yet files that had already been created needed to be changed to 777. Why is this?

Hi Bob -

The web site is still not working properly, so I'm assuming that the three directories are still "invisible". Can you have another go at resetting their permissions, please?

I had a look but cannot remembr if I fixed the problem. If not just say and i'll take another look.

Bob

Did you get my email about my website directories still being inaccessible, even after you reset them?

They are more safe but not entirly hack proof.

So, are files safer in the Root rather than in the htdocs folder??

OK, the problem is that the web server runs as the same user for all sites. As such if the files need to be modified by a script then they need to able to be modified by the web server. And if they can be modified by the web server then they can be modified by anything. On the old servers you only needed group write and this was even less secure. Now if you files do not need to be modified by the server then do not enable group or everyone write and they will be secure. If they need to be moded by the server then they will be insecure. No way around it without running a seperate web server for every user.

Didn't know the ../ thing would work back as far as the Root, thanx.