|
Problems writing to the server
I am having problems writing a file (in fact, it`s a Google sitemap) to a site.
I know that it has something to do with permissions and owners. But how can I see what the settings are for this file? And what "owner" will PHP be known as?
Comments
I am having problems writing a file (in fact, it`s a
That depends on the operating system of the server which provides your web
hosting. In most cases you will have a particular user for login/SFTP/scp. The
webserver user is normally different (a good thing) and many Apache
installations will use a nonprivileged user such as "nobody" or "apache" or
"httpwww" or something similar.
If you have command-line access (ie ssh) to the server, you can perform some
basic commands (ie Linux or Unix`s ls -l) to see the permissions and ownership
of your files. If you don`t have this access, your SFTP/scp (you aren`t still
using regular unsecure FTP right?) client program likely has a command to see
and possibly set some values.
As always, be careful with ownership and permissions. As soon as you have a
file or directory which can be written by PHP, there is an opportunity for an
outsider to abuse it.
Yes, I can visit this dedicated server with PuTTy.
I see 2 columns, I guess this is permission and owner.
In some places, one or both of the columns is pete (me), in some places
a previous programmer, and there is also one root, and a few apache.
I am going to look into "owners and permissions", now that you have
pointed me in the right direction, but can you give me a quick fix for
this file? It`s marked as pete and pete. I think that I should either
change it (no idea how) to apache, or perhaps delete it?
Files are normally uploaded using SSH/Subversion, but sometimes they are
manually uploaded by secure FTP. I expect that is the difference. And
I also expect that this is why, if I upload a file manually, svn
sometimes crashes when it tries to upload.
Well, I admit to unsecure FTP in places. Is this because of sniffing
out passwords?
The Google sitemap will be re-created every night, *I* wouldn`t think
that it would be an issue if someone overwrote it for a few hours...
although I am not sure how it could be done.
Do you have any links for info about unsecure FTP, and issues with
directories available to written by PHP?
Hi,
This issue can be quite different on different servers depending
on how php is running.
The most common setup is to have php running as an Apache application. In
this setup http: accessible scripts run with the authority of the default
www user. Most often the default www user is `default`, `www`, `www_data`,
`apache` or `nobody`.
FTP however most often has the authority of the specific hosting account
owner. So if your FTP login name is `john" then files uploaded by `john`
have the owner `john`.
On some servers php runs as a CGI which is totally different. In this setup
the scripts that are accessed via http: run with the authority of the
account owner.
Also on some servers there is an option to run a `wrapper` or `cgi wrapper`
or `authority wrapper` or `owner wrapper` so that optional scripts run with
the account owners authority while others run with the `default user`
authority even when php is running as an Apache application. This however is
less common.
Putting this all together -
Firstly, you have to determine who is the file owner.
In most cases any file that is uploaded via private FTP will be owned by the
account owner.
Files that have been created by scripts have the owner of the authority that
the creating script was running under. Normally this is the `default www
user` however if you are using a wrapper or running php as a CGI then the
owner will most likely be the actual hosting account owner.
So if the script runs as `default www user` then `default www user` will be
the owner of the created file. However if the script is running with the
authority of the hosting account owner then the hosting account owner will
be the owner of the created file.
This is why most people have their first trouble when they shift hosting
accounts. All the original scripts that were uploaded in the first place
transfer across fine but files that were created by these scripts often
change owner from the `default www user` to the account owner due to the FTP
process from one server to another.
Most people get around this by changing file/folder permission`s and in the
process they compromise the security of their scripts.
How Apache file attributes work -
In Apache there are 3 authorities of access and 3 access controls for each
of the authorities.
The authorities are -
Owner - is the actual owner of the hosting account.
Group - is the collective group of authorised account owners on a server or
subusers that have been authorised for your account via `basic auth` login
protocol.
User - is the default www user or just anyone using a browser or http:
access.
The controls are (for files) -
Read - read access to be able to read a file - in php via http: the file is
parsed so the assessor only sees the results of the code.
Write - Modify/delete access to the file.
Execute - this give the ability to execute code etc.
The controls for folders have different meanings.
The controls are (for folders) -
Read - is the ability to list the files/subfolder in a folder.
Write - is the ability to create, modify or delete files or subfolders in
the folder.
Execute - is the ability to access (in anyway) files in the folder - like
the meaning of read is for files.
So if a script needs to create an read files there are two real options -
1) If the script runs as the account owner then the file has to at least
have permission`s 600 and the folder that contains the folder needs at least
300.
2) If the script runs as the `default www user` then the file needs at least
660 and the folder needs at least 330.
In reality you are not so concerned with owner access restrictions so these
permission`s would translate to -
600 => 700
300 => 700
660 => 760
330 => 730
However if your script runs in the owners authority then it is best restrict
access to the bare minium (first permission`s) without this translation.
FTP and cPanel do not show file owners which makes things hard. To use php
to see the file owners then read up on POSIX functions in php.
To work blind, in most cases you can write a simple script that uploads
files via the http: POST method and these will match the owner of other
script created files. This can be done with a textarea html element for
simple text files. For binary files you have to use the php $_FILES method.
For text file use -
$posted_text = $_POST[`textarea_name`];// as in <textarea name=???
str_replace("rn", "r", $posted_text);
str_replace("r", "n", $posted_text);
- to standardise the line delimiter while maintaining white space.
I did start to write a file/folder browser like windows explorer that shows
owner information but didn`t finish it ;-( when I do finish it then I will
upload it to the files section of this group.
Clear as Mud??
Hope this helps.
Hi,
<big snip>
Sorry got the permissions wrong!
It should have read - .....
So if a script needs to create an read files there are two real options -
1) If the script runs as the account owner then the file has to at least
have permission`s 600 and the folder that contains the folder needs at least
300.
2) If the script runs as the `default www user` then the file needs at least
606 and the folder needs at least 303.
In reality you are not so concerned with owner access restrictions so these
permission`s would translate to -
600 => 700
300 => 700
606 => 706
303 => 703
In general, the `group` access is set to the same as the `owner` access but
this is not a good thing if you are on a shared server and have things like
credit card numbers in files. The only time the `group` access needs to be
anything other than 0 is when you are using `basic auth` protocol or you
have subusers with FTP accounts.
<another big snip>
Permissions
-----------
On a Unix-like system, an ls -l command displays permissions and ownership for
each file or directory displayed. The first part is a series of symbols to
describe the permissions. For example a typical directory and file may have
these permissions:
drwxr-xr-x dir
-rw-r--r-- file
The first column with a d (for directory) or - (for file) identifies the type of
resource being listed. There are other options such as l (for symbolic link), b
(for block device), etc.
After this there are three groupings of "rwx" for read, write, execute. If a
value is represented by a - then it is off for that user. There is a binary
value associated with each bit position in the permission values: r=4, w=2,
x=1. Add the values for each one which is on. In the examples above, the
directory has permissions of 755 (4+2+1=7, 4+0+1=5) and the file is 644
(4+2+0=6, 4+0+0=4).
New files or new directories will often get permissions like the samples based
on the umask setting. Running the umask command will reveal the current value
for your user. For these examples, it will usually be 0022.
The three groupings relate to the owner of the file or directory, group
associated with the file or directory, and every other user on the system.
The name of the user and the name of the group are identified in an ls -l
listing. The first name is the owner and the second is the group. Normally, a
non-privileged user can only set group associations on a file or directory if
they are a member of that group.
It can be useful to set the ownership of the file to the log-in user (you) and
the group to the webserver user (often "nobody" or "apache", etc.). Then, if
you used permissions of 664, you could write to the file, the members of the
group could write to the file, but other users could not. However, in a shared
hosting environment, any PHP script on the server could, in theory, write to the
file.
The same sort of problems exist if you set a file`s permissions to 666. Then
the owner, members of the group, and any other user have read and write
permissions on the file.
You say that it`s not a big deal if someone can overwrite the file. However, if
they are able to write to it, they can change its name. If they can do that,
they can write PHP or other executable content and do all sorts of damage until
the file can be restored to a proper value.
Files which are writeable by users other than the owner should not be in the
main web space. Often you will have a directory above or otherwise outside the
web space which is considered a "home" directory of sorts. You could put a
writeable file or directory and let PHP scripts access this.
A prime example of this issue is where to store files uploaded by web users to
your page, especially anonymous ones. The files should be placed in a directory
outside of the web space. Then, when the content of the files needs to display
these to the web, create a handler script to access the non-web directory. This
script can check to ensure that the user is logged in, file is a certain type,
etc., before the file contents are grabbed
|
|
