So in summary this can't be done due to permission problems?

As part of a CMS I wanted to get the user to:
1) Create a new recordset via a form (with a uniqueid).
2) Press submit whereupon php gets the ID of the record just created in
the DB, writes a new page to the server with that unique id and saves it
as a filename determined by the user.

No way around that due to permission settings on the webroot?

So there is no way that PHP can write to the server unless the directory
it's writing in is executable?
Thanks for continued help.
Cheers,

Steve Jackson
Web Development and Marketing Manager
Viola Systems Ltd.
http://www.violasystems.com
stephen.jackson@violasystems.com
Mobile +358 50 343 5159

--- Steve Jackson <stephen.jackson@violasystems.com> wrote:
> As part of a CMS I wanted to get the user to:
> 1) Create a new recordset via a form (with a uniqueid).
> 2) Press submit whereupon php gets the ID of the record just
> created in
> the DB, writes a new page to the server with that unique id and
> saves it
> as a filename determined by the user.
>
> No way around that due to permission settings on the webroot?
>
> So there is no way that PHP can write to the server unless the
> directory
> it's writing in is executable?

That is correct. According to the docs, if the directory is not
executable, you can't even get the permissions on the files in it.
I'm confused, though.

Let me state at the begining that I'm not a linux guy. Learning, but
slowly.

-Doesn't PHP run as some user?

-Is the issue giving that user execute permissions in the web root?

-Why the concern about letting that user have execute permissions,
and then prevent anyone (execpt those that have valid reasons) from
having write/execute permission to the webroot.

Am I missing something basic? Quite possibly...


=====
Mark Weinstock
mark_weinstock@yahoo.com
***************************************
You can't demand something as a "right" unless you are willing to fight to death to defend everyone else's right to the same thing.
***************************************

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

On Friday, July 11, 2003, 5:07:49 PM, Mark wrote:

[ snip ]

M> That is correct. According to the docs, if the directory is not
M> executable, you can't even get the permissions on the files in it.
M> I'm confused, though.

M> Let me state at the begining that I'm not a linux guy. Learning, but
M> slowly.

M> -Doesn't PHP run as some user?

PHP runs with the same permissions as Apache.

M> -Is the issue giving that user execute permissions in the web root?

If Apache cannot create a file in a directory, then PHP can't do it
either.

M> -Why the concern about letting that user have execute permissions,
M> and then prevent anyone (execpt those that have valid reasons) from
M> having write/execute permission to the webroot.

I don't think the problem is with execute permissions. It just needs
to be able to write and read from a directory, not necessarily
execute. Although I'm not too sure about this.

M> Am I missing something basic? Quite possibly...

This isn't the easiest of things...



--
Regards,
Burhan Khalid
phplist[at]meidomus[dot]com
http://www.meidomus.com

File and directory permissions (so that people searching the archives have
something to look for).

> That is correct. According to the docs, if the directory is not
> executable, you can't even get the permissions on the files in it.
> I'm confused, though.

1) To be able to _access_ a directory and its contents you need at minimum,
execute permissions, on all directories in the path.

2) To be able to create files (ie write _new_ files) in a directory, you need
write permission for the directory in which the file is to be created (as
well as (1)).

3) To be able to change the contents of existing files you need (1) and you
need write permissions on the file that you want to change.

4) To be able to rename files, you need (1) and read permissions on the source
files and (2) on the destination directory.

5) To be able to _list_ the contents of a directory (as opposed to just having
_access_) then you need (1) and read permissions on that directory.


> -Doesn't PHP run as some user?

Yes, usually as the user which runs the webserver.

> -Is the issue giving that user execute permissions in the web root?

Not just execute, you need write as well.

> -Why the concern about letting that user have execute permissions,
> and then prevent anyone (execpt those that have valid reasons) from
> having write/execute permission to the webroot.

Because in many shared-hosting environments, such an arrangement will mean
that your fellow co-hosts will be able to read/write/trash files in your web
space.

That is why it was suggested that the OP used the FTP functions to write the
files into his own web space.

--
Jason Wong -> Gremlins Associates -> www.gremlins.biz
Open Source Software Systems Integrators
* Web Design & Hosting * Internet & Intranet Applications Development *
------------------------------------------
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
------------------------------------------
/*
Stone's Law:
One man's "simple" is another man's "huh?"
*/

Thanks to all who explained it to me. Sorry if I inadvertently
hijacked the thread.

--- Jason Wong <php-general@gremlins.biz> wrote:
> File and directory permissions (so that people searching the
> archives have
> something to look for).
>
> > That is correct. According to the docs, if the directory is not
> > executable, you can't even get the permissions on the files in
> it.
> > I'm confused, though.
>
> 1) To be able to _access_ a directory and its contents you need at
> minimum,
> execute permissions, on all directories in the path.
>
> 2) To be able to create files (ie write _new_ files) in a
> directory, you need
> write permission for the directory in which the file is to be
> created (as
> well as (1)).
>
> 3) To be able to change the contents of existing files you need (1)
> and you
> need write permissions on the file that you want to change.
>
> 4) To be able to rename files, you need (1) and read permissions on
> the source
> files and (2) on the destination directory.
>
> 5) To be able to _list_ the contents of a directory (as opposed to
> just having
> _access_) then you need (1) and read permissions on that directory.
>
>
> > -Doesn't PHP run as some user?
>
> Yes, usually as the user which runs the webserver.
>
> > -Is the issue giving that user execute permissions in the web
> root?
>
> Not just execute, you need write as well.
>
> > -Why the concern about letting that user have execute
> permissions,
> > and then prevent anyone (execpt those that have valid reasons)
> from
> > having write/execute permission to the webroot.
>
> Because in many shared-hosting environments, such an arrangement
> will mean
> that your fellow co-hosts will be able to read/write/trash files in
> your web
> space.
>
> That is why it was suggested that the OP used the FTP functions to
> write the
> files into his own web space.
>
> --
> Jason Wong -> Gremlins Associates -> www.gremlins.biz
> Open Source Software Systems Integrators
> * Web Design & Hosting * Internet & Intranet Applications
> Development *
> ------------------------------------------
> Search the list archives before you post
> http://marc.theaimsgroup.com/?l=php-general
> ------------------------------------------
> /*
> Stone's Law:
> One man's "simple" is another man's "huh?"
> */
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>


=====
Mark Weinstock
mark_weinstock@yahoo.com
***************************************
You can't demand something as a "right" unless you are willing to fight to death to defend everyone else's right to the same thing.
***************************************

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

> As part of a CMS I wanted to get the user to:
> 1) Create a new recordset via a form (with a uniqueid).
> 2) Press submit whereupon php gets the ID of the record just created in
> the DB, writes a new page to the server with that unique id and saves it
> as a filename determined by the user.

Seriously, aren't you really just trying to re-invent sessions?

A cookie tracks your session id, your php uses the session id to
maintain persistent data on the visitor, you use the persistent data to
customize the page that gets presented. You don't need to know about
file permissions beyond setting up apache and php.

If you want more than sessions can give you, then you probably want to
set up a directory that is not underneath your web root (maybe under /var
somewhere?) and is only accessible to your apache user. The functions to
read and write files in that directory should be declared in include
files, which should also not be underneath your web root.

If you want to really tighten the lid down, you can set up a separate
server process and communicate with it through local sockets instead of
IP. Or you could install a database and configure the database to not listen
to anything coming in over the network.

--
Joel Rees, programmer, Kansai Systems Group
Altech Corporation (Alpsgiken), Osaka, Japan
http://www.alpsgiken.co.jp