chmod questions |
chmod questions |
Christian J |
Apr 24 2009, 05:55 PM
Post
#1
|
. Group: WDG Moderators Posts: 9,656 Joined: 10-August 06 Member No.: 7 |
1. http://en.wikipedia.org/wiki/Chmod#Command_line_examples says that
QUOTE chmod 664 file sets read and write access for the owner, the group, and not for all others. Is that correct? In my FTP program (FileZilla) 664 will also give Other read permissions: CODE Owner rw Group rw Other r 2. I've chmoded a file to 660, which according to FileZilla means CODE Owner rw Group rw Other but still the file can be viewed in a browser. Don't browsers belong to the Other category? If not, what does? |
Darin McGrew |
Apr 24 2009, 06:07 PM
Post
#2
|
WDG Member Group: Root Admin Posts: 8,365 Joined: 4-August 06 From: Mountain View, CA Member No.: 3 |
Yes, 664 is read-write for owner and group, and read-only for others.
Yes, 660 is read-write for owner and group, and no access for others. Usually, browsers don't access the filesystem. The server accesses the filesystem. Depending on the group ownership of the files and the account used to run the server, the server could be owner, group, or other. |
Christian J |
Apr 24 2009, 06:57 PM
Post
#3
|
. Group: WDG Moderators Posts: 9,656 Joined: 10-August 06 Member No.: 7 |
Yes, 664 is read-write for owner and group, and read-only for others. Yes, 660 is read-write for owner and group, and no access for others. Thanks for the sanity check. QUOTE Usually, browsers don't access the filesystem. The server accesses the filesystem. Depending on the group ownership of the files and the account used to run the server, the server could be owner, group, or other. If I understood this right, doesn't it make chmod permission settings rather ambiguous unless you know what belongs to what group? Can you find out what belongs to what group? On my (AFAIK) virtual host account I have to chmod Group rw to make PHP read/write to a file, which at the same time makes the file viewable to the web (which seems to make Other redundant). Is there any way I can give the PHP engine and the web separate permissions? |
Darin McGrew |
Apr 24 2009, 07:31 PM
Post
#4
|
WDG Member Group: Root Admin Posts: 8,365 Joined: 4-August 06 From: Mountain View, CA Member No.: 3 |
If I understood this right, doesn't it make chmod permission settings rather ambiguous unless you know what belongs to what group? Can you find out what belongs to what group? The command `ls -lg` shows you the access mode, owner, and group of a file, among other things. But that doesn't help you know how the server is configured. I've seen servers configured to run as root (a bad idea, the server has access to everything regardless of access modes), as nobody (only access to "other" matters), or as other accounts (access to "owner" and/or "group" matters). You just need to know how the server is running.On my (AFAIK) virtual host account I have to chmod Group rw to make PHP read/write to a file, which at the same time makes the file viewable to the web (which seems to make Other redundant). Is there any way I can give the PHP engine and the web separate permissions? I'm not familiar with PHP, but with other server-side mechanisms you can put the data somewhere outside the DocumentRoot path, so it isn't available as a normal web page at all. |
Christian J |
Apr 25 2009, 05:37 AM
Post
#5
|
. Group: WDG Moderators Posts: 9,656 Joined: 10-August 06 Member No.: 7 |
I'm not familiar with PHP, but with other server-side mechanisms you can put the data somewhere outside the DocumentRoot path, so it isn't available as a normal web page at all. Seems I must do something like that, or maybe deny file viewing with a .htaccess directive (which apparently doesn't affect PHP). |
Brian Chandler |
Apr 25 2009, 07:43 AM
Post
#6
|
Jocular coder Group: Members Posts: 2,460 Joined: 31-August 06 Member No.: 43 |
I'm not familiar with PHP, but with other server-side mechanisms you can put the data somewhere outside the DocumentRoot path, so it isn't available as a normal web page at all. Seems I must do something like that, or maybe deny file viewing with a .htaccess directive (which apparently doesn't affect PHP). As I remember (which isn't very clearly), pair.com runs the webserver as "something else" (nobody, perhaps), so to make writing files and stuff sane in PHP I had to copy the php executable to somewhere in my file space, and change something so that php runs as me. Then files can be protected with 700 if necessary. On a shared server you have to remember that if files are accessible by the server using the 'group' permissions, it means that any other (human) user of the same server has access to them. Of course .htaccess is a set of server (Apache) irectives, so it doesn't affect any other programs running on the server (box). |
Christian J |
Apr 25 2009, 10:22 AM
Post
#7
|
. Group: WDG Moderators Posts: 9,656 Joined: 10-August 06 Member No.: 7 |
On a shared server you have to remember that if files are accessible by the server using the 'group' permissions, it means that any other (human) user of the same server has access to them. Doesn't that mean that another customer of your hosting company may even write to your files using server file paths like "././web_root/file.txt"? Putting the writeable files above the web root doesn't seem to make any difference (assuming location and file name are known somehow). |
Brian Chandler |
Apr 25 2009, 01:07 PM
Post
#8
|
Jocular coder Group: Members Posts: 2,460 Joined: 31-August 06 Member No.: 43 |
On a shared server you have to remember that if files are accessible by the server using the 'group' permissions, it means that any other (human) user of the same server has access to them. Doesn't that mean that another customer of your hosting company may even write to your files using server file paths like "././web_root/file.txt"? Putting the writeable files above the web root doesn't seem to make any difference (assuming location and file name are known somehow). Yes, of course. If a file is writable by [category x], then any member of [category x] can write to it. Well, I don't understand what ././ is supposed to do (nothing, I think)... Hmm, interesting: I'm sure I used to be able to read the list of user names on our server, but pair have disabled even read access to the directories. This stops casual skimming of user lists at least. If I happened to know that user swan had a writable file (as I think you have/had?) somewhere, yes I could write over it from my home directory by simply accessing ../swan/whatever. This is why 644 is a general default -- files are open to be read, but only written by the owner. |
Christian J |
Apr 25 2009, 02:38 PM
Post
#9
|
. Group: WDG Moderators Posts: 9,656 Joined: 10-August 06 Member No.: 7 |
|
Lo-Fi Version | Time is now: 25th April 2024 - 10:31 PM |