File upload permissions

[eclipsme]

I thought I had this licked, but apparently not.

I have a file upload script that attempts to upload a file to a
directory in the public_html directory - www.domain.com/upload

The permissions for the directory have to be 777 for this to work or
esle it aborts with a permissions error - obviously a problem. The php
script runs as user 'nobody'.

Tech support is through email, and level one is not that bright, or at
least not that fluent in english. I am trying to get the exact phrase to
tell them. Is it that I need them to set the group to nobody or add
nobody to the group or???

Am I on the right path? If 'nobody' was a member of the group, I could
use 775, right?

Thanks for the help,
Harvey

[=?ISO-8859-1?Q?=22=C1lvaro_G=2E_Vicario=22?=]

eclipsme escribió:

I thought I had this licked, but apparently not.

I have a file upload script that attempts to upload a file to a
directory in the public_html directory - www.domain.com/upload

The permissions for the directory have to be 777 for this to work or
esle it aborts with a permissions error - obviously a problem. The php
script runs as user 'nobody'.

Tech support is through email, and level one is not that bright, or at
least not that fluent in english. I am trying to get the exact phrase to
tell them.

You can change the directory permissions yourself with any decent FTP
client. If you don't have FTP access, some control panels have this
feature too.

Is it that I need them to set the group to nobody or add
nobody to the group or???

Yes, changing the file ownership is another option.

Am I on the right path? If 'nobody' was a member of the group, I could
use 775, right?

Or even 770. Permissions digits mean: user/group/others. Just be aware
that user "nobody" is not the same as group "nobody"; what happens is
that when you create a new user, most distros create a group with the
same name as the user and add the user to the group as its only member.

The request should be something as "I need to change the ownership of
directory ~/public_html/upload so it belongs to the nobody group. I need
it to allow file uploads from my web site.".
--
-- http://alvaro.es - Álvaro G. Vicario - Burgos, Spain
-- Mi sitio sobre programación web: http://bits.demogracia.com
-- Mi web de humor al baño María: http://www.demogracia.com
--

[eclipsme]

Álvaro G. Vicario wrote:

eclipsme escribió:

>I thought I had this licked, but apparently not.

I have a file upload script that attempts to upload a file to a
directory in the public_html directory - www.domain.com/upload

The permissions for the directory have to be 777 for this to work or
esle it aborts with a permissions error - obviously a problem. The php
script runs as user 'nobody'.

Tech support is through email, and level one is not that bright, or at
least not that fluent in english. I am trying to get the exact phrase
to tell them.

You can change the directory permissions yourself with any decent FTP
client. If you don't have FTP access, some control panels have this
feature too.

>Is it that I need them to set the group to nobody or add nobody to the
group or???

Yes, changing the file ownership is another option.

>Am I on the right path? If 'nobody' was a member of the group, I could
use 775, right?

Or even 770. Permissions digits mean: user/group/others. Just be aware
that user "nobody" is not the same as group "nobody"; what happens is
that when you create a new user, most distros create a group with the
same name as the user and add the user to the group as its only member.

The request should be something as "I need to change the ownership of
directory ~/public_html/upload so it belongs to the nobody group. I need
it to allow file uploads from my web site.".

Thanks for this!

Harvey

[eclipsme]

eclipsme wrote:

Álvaro G. Vicario wrote:

>eclipsme escribió:

>>I thought I had this licked, but apparently not.

I have a file upload script that attempts to upload a file to a
directory in the public_html directory - www.domain.com/upload

The permissions for the directory have to be 777 for this to work or
esle it aborts with a permissions error - obviously a problem. The
php script runs as user 'nobody'.

Tech support is through email, and level one is not that bright, or
at least not that fluent in english. I am trying to get the exact
phrase to tell them.

You can change the directory permissions yourself with any decent FTP
client. If you don't have FTP access, some control panels have this
feature too.

Right, but the problem I am facing is that permissions need to be 777 -
not the best option, right? So I am correct to pursue the ownership
issue, right? I just got an email back from support saying they did
this, but I am still getting a permissions error when the script tries
to move the file from the temp directory to the actual.

Harvey

[Gordon Burditt]

>Right, but the problem I am facing is that permissions need to be 777 -

>not the best option, right?

The REASON 777 permissions are not the best option is primarily the
risk of tampering by the other people renting space on the same
host. (If you don't trust your host's admins, change hosts, but
you're really stuck with trusting someone's admins on a shared
host). You have the same problem with mode 770, group nobody. The
other people renting space (your competitors) can also run programs
with that user ID.

>So I am correct to pursue the ownership
issue, right? I just got an email back from support saying they did
this, but I am still getting a permissions error when the script tries
to move the file from the temp directory to the actual.

So what are the owner/permissions on THAT directory?

[eclipsme]

Gordon Burditt wrote:

>Right, but the problem I am facing is that permissions need to be 777 -
not the best option, right?

The REASON 777 permissions are not the best option is primarily the
risk of tampering by the other people renting space on the same
host. (If you don't trust your host's admins, change hosts, but
you're really stuck with trusting someone's admins on a shared
host). You have the same problem with mode 770, group nobody. The
other people renting space (your competitors) can also run programs
with that user ID.

>So I am correct to pursue the ownership
issue, right? I just got an email back from support saying they did
this, but I am still getting a permissions error when the script tries
to move the file from the temp directory to the actual.

So what are the owner/permissions on THAT directory?

Oh. I thought the problem was that anybody could upload a script to a
directory with 777 and run it. I wasn't thinking of others on the shared
host.

Also, not sure what you mean by "THAT" directory. This is the directory
that I am trying to get them to change - the directory that the file
will end up in. I have the permissions set to 770, but don't know hoe to
check the ownership. BTW - after going one more round with them, 3 of 6
folders are now working. It *would* be nice if I coould check the
ownership of them How do I do that?

Harvey

[Gordon Burditt]

>>Right, but the problem I am facing is that permissions need to be 777 -

>>not the best option, right?

The REASON 777 permissions are not the best option is primarily the
risk of tampering by the other people renting space on the same
host. (If you don't trust your host's admins, change hosts, but
you're really stuck with trusting someone's admins on a shared
host). You have the same problem with mode 770, group nobody. The
other people renting space (your competitors) can also run programs
with that user ID.

>>So I am correct to pursue the ownership
issue, right? I just got an email back from support saying they did
this, but I am still getting a permissions error when the script tries
to move the file from the temp directory to the actual.

So what are the owner/permissions on THAT directory?

Oh. I thought the problem was that anybody could upload a script to a
directory with 777 and run it.

The "and run it" part isn't true if it's not inside the document
tree (and if it is inside the document tree, that's incredibly
dangerous). FTP by itself doesn't have a command to run a file on
the server. This assumes that "anybody" doesn't have a shell
account.

>I wasn't thinking of others on the shared
host.

Also, not sure what you mean by "THAT" directory.

You mentioned that the script tries to move the file from one
directory to another (That's two directories). You got the permissions
changed on one directory. I'm referring to the OTHER one. Or the
other three of six mentioned below, or whatever. If you're really
trying to move (rename) the file, you need to worry about permissions
on the source (so you can delete it) and destination (so you can
create files there) directories.

>This is the directory
that I am trying to get them to change - the directory that the file
will end up in. I have the permissions set to 770, but don't know hoe to
check the ownership.

Look at the PHP function stat(), or fileowner() and filegroup() to
get the uid and gid of the owner of the file. Use posix_getpwuid()
and posix_getgrgid() to translate uid and gid into names. fileperms()
might be useful also (display it in octal).

>BTW - after going one more round with them, 3 of 6
folders are now working. It *would* be nice if I coould check the
ownership of them How do I do that?

[eclipsme]

Perhaps I have not approached this correctly and need to rethink it.
Please, let me tell you what I am trying to do. Perhaps there is a
better way.

The database is for agendas, minutes and audio of various city meetings.
Each 'agency', like the city council, or redevelopment, has its own
table. The table holds only the name of the file, and the path to the
file is coded in the web pages.

I have written a script that takes input from a form,
enctype="multipart/form-data" and fields, type="file", and uses the PHP
command 'move_uploaded_file' to put the file where I want it. The script
then updates the database. This is the 'OTHER' directory referred to -
PHP uploads to a tmp directory then moves it to the final destination.
This is not important, I think, to the discussion.

You say, the "and run it" part isn't true if it's not inside the
document tree (and if it is inside the document tree, that's incredibly
dangerous)."

The directories *are* in the tree - /public_html/CRA/agendas, for
instance. This is what you are referring to as incredibly dangerous,
right? This is why I wanted to be able to limit permissions to 775. Is
the real problem where I am saving these files? Mind you, the files are
public files. I don't care if people can access them directly. I do care
if scripts or other files can be loaded by others.

Do I need to redo and keep these files below the web root? If so, will
these permission issues still apply? Will 777 be ok?

Finally, how does a web page access these files?

Thank so much for taking the time.
Harvey

[Jerry Stuckle]

eclipsme wrote:

Perhaps I have not approached this correctly and need to rethink it.
Please, let me tell you what I am trying to do. Perhaps there is a
better way.

The database is for agendas, minutes and audio of various city meetings.
Each 'agency', like the city council, or redevelopment, has its own
table. The table holds only the name of the file, and the path to the
file is coded in the web pages.

I have written a script that takes input from a form,
enctype="multipart/form-data" and fields, type="file", and uses the PHP
command 'move_uploaded_file' to put the file where I want it. The script
then updates the database. This is the 'OTHER' directory referred to -
PHP uploads to a tmp directory then moves it to the final destination.
This is not important, I think, to the discussion.

You say, the "and run it" part isn't true if it's not inside the
document tree (and if it is inside the document tree, that's incredibly
dangerous)."

The directories *are* in the tree - /public_html/CRA/agendas, for
instance. This is what you are referring to as incredibly dangerous,
right? This is why I wanted to be able to limit permissions to 775. Is
the real problem where I am saving these files? Mind you, the files are
public files. I don't care if people can access them directly. I do care
if scripts or other files can be loaded by others.

Do I need to redo and keep these files below the web root? If so, will
these permission issues still apply? Will 777 be ok?

Finally, how does a web page access these files?

Thank so much for taking the time.
Harvey

Look at the file extension, and only allow certain extensions to be
uploaded.

If your webserver is set up correctly, it won't execute .txt, .pdf, etc.
files. It will just serve them.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[eclipsme]

Jerry Stuckle wrote:

eclipsme wrote:

>Perhaps I have not approached this correctly and need to rethink it.
Please, let me tell you what I am trying to do. Perhaps there is a
better way.

The database is for agendas, minutes and audio of various city
meetings. Each 'agency', like the city council, or redevelopment, has
its own table. The table holds only the name of the file, and the path
to the file is coded in the web pages.

I have written a script that takes input from a form,
enctype="multipart/form-data" and fields, type="file", and uses the
PHP command 'move_uploaded_file' to put the file where I want it. The
script then updates the database. This is the 'OTHER' directory
referred to - PHP uploads to a tmp directory then moves it to the
final destination. This is not important, I think, to the discussion.

You say, the "and run it" part isn't true if it's not inside the
document tree (and if it is inside the document tree, that's incredibly
dangerous)."

The directories *are* in the tree - /public_html/CRA/agendas, for
instance. This is what you are referring to as incredibly dangerous,
right? This is why I wanted to be able to limit permissions to 775. Is
the real problem where I am saving these files? Mind you, the files
are public files. I don't care if people can access them directly. I
do care if scripts or other files can be loaded by others.

Do I need to redo and keep these files below the web root? If so, will
these permission issues still apply? Will 777 be ok?

Finally, how does a web page access these files?

Thank so much for taking the time.
Harvey

Look at the file extension, and only allow certain extensions to be
uploaded.

If your webserver is set up correctly, it won't execute .txt, .pdf, etc.
files. It will just serve them.

I have included this checking in the script. So, are you saying that
having these files in the tree is ok? and that 777 would be ok?

Sorry to be such a bother.

Harvey

[Jerry Stuckle]

eclipsme wrote:

Jerry Stuckle wrote:

>eclipsme wrote:

>>Perhaps I have not approached this correctly and need to rethink it.
Please, let me tell you what I am trying to do. Perhaps there is a
better way.

The database is for agendas, minutes and audio of various city
meetings. Each 'agency', like the city council, or redevelopment, has
its own table. The table holds only the name of the file, and the
path to the file is coded in the web pages.

I have written a script that takes input from a form,
enctype="multipart/form-data" and fields, type="file", and uses the
PHP command 'move_uploaded_file' to put the file where I want it. The
script then updates the database. This is the 'OTHER' directory
referred to - PHP uploads to a tmp directory then moves it to the
final destination. This is not important, I think, to the discussion.

You say, the "and run it" part isn't true if it's not inside the
document tree (and if it is inside the document tree, that's incredibly
dangerous)."

The directories *are* in the tree - /public_html/CRA/agendas, for
instance. This is what you are referring to as incredibly dangerous,
right? This is why I wanted to be able to limit permissions to 775.
Is the real problem where I am saving these files? Mind you, the
files are public files. I don't care if people can access them
directly. I do care if scripts or other files can be loaded by others.

Do I need to redo and keep these files below the web root? If so,
will these permission issues still apply? Will 777 be ok?

Finally, how does a web page access these files?

Thank so much for taking the time.
Harvey

Look at the file extension, and only allow certain extensions to be
uploaded.

If your webserver is set up correctly, it won't execute .txt, .pdf,
etc. files. It will just serve them.

I have included this checking in the script. So, are you saying that
having these files in the tree is ok? and that 777 would be ok?

Sorry to be such a bother.

Harvey

777 has nothing to do with whether the file is executable or not. It
has EVERYTHING to do with security from other users on your shared host.

No, it is NOT good to have 777. In fact, I would say 640 is the most
you should have (web scripts are NOT executable).

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[eclipsme]

>
777 has nothing to do with whether the file is executable or not. It
has EVERYTHING to do with security from other users on your shared host.

No, it is NOT good to have 777. In fact, I would say 640 is the most
you should have (web scripts are NOT executable).

Thank you Jerry. I jumped into this project without thinking it through
all the way. Of course, when you are learning that is pretty much how it
happens.

Now that I have a script that is working - except for this whole
permissions issue - I see that PHP as FTP commands, which I didn't
realize in the beginning. Perhaps it would be better to use ftp_put()
instead of move_uploaded_file()???

Perhaps this calls for a new topic.

Harvey

[Jerry Stuckle]

eclipsme wrote:

>

>>
777 has nothing to do with whether the file is executable or not. It
has EVERYTHING to do with security from other users on your shared host.

No, it is NOT good to have 777. In fact, I would say 640 is the most
you should have (web scripts are NOT executable).

Thank you Jerry. I jumped into this project without thinking it through
all the way. Of course, when you are learning that is pretty much how it
happens.

Now that I have a script that is working - except for this whole
permissions issue - I see that PHP as FTP commands, which I didn't
realize in the beginning. Perhaps it would be better to use ftp_put()
instead of move_uploaded_file()???

Perhaps this calls for a new topic.

Harvey

No, you need to use move_uploaded_file() to move the file from the
temporary location to the permanent one.

What you need to do is to get your hosting company to straighten out
your group memberships.

And BTW - I forgot you were talking about a directory; 640 should be for
files. A directory should be something like 750 or 770, but never 777.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[Charles Calvert]

On Tue, 04 Nov 2008 07:04:59 -0500, eclipsme <ec******@nowhere.com>
wrote in <XR*******************@bignews4.bellsouth.net>:

[snip]

>The database is for agendas, minutes and audio of various city meetings.
Each 'agency', like the city council, or redevelopment, has its own
table. The table holds only the name of the file, and the path to the
file is coded in the web pages.

This is OT, but FYI, unless there's a compelling reason to have
separate tables, all of these entries should be in a single table with
an additional column that contains the primary key of the record that
identifies the agency. Something like:

CREATE TABLE agencies (
id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY
, name VARCHAR(255) NOT NULL
);

CREATE TABLE minutes (
id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY
, agency_id INTEGER NOT NULL
, filename VARCHAR(255) NOT NULL
, CONSTRAINT FK_minutes_agencies FOREIGN KEY (
agency_id
) REFERENCES agencies (id)
);

You can then write an interface in your application that allows the
administration of the agencies. If a new agency is added, you just
add a record to the table agencies and start adding records to the
table minutes. With a separate table per agency, you'd have to add a
new table and modify your code.

This isn't really a PHP issue, so I suggest following up in an
appropriate database group, such as comp.databases.mysql.
--
Charles Calvert | Web-site Design/Development
Celtic Wolf, Inc. | Software Design/Development
http://www.celticwolf.com/ | Data Conversion
[phone] | Project Management