phprojekt-devel

[Phprojekt-devel] Private folder on P6

[Gustavo S. <gus...@gm...>]

Hi all,
 since many people complain about the "DocumentRoot" limitation in the
installation of PHProjekt 6, for a better solution about the security,
there is an idea about to make 2 improves:

1. Make the configuration.ini file, a php file, so nobody can read it,
only the web server can execute it or read it.

2. Make a private folder for save there the logs, the temporally and the
uploaded files. (All the files written by the API/User).

--- About 1. ---
The best solution that i found, is to keep the configuration.ini file as
format, add a <?php in the first line, rename it to configuration.php
and change the comments from ; to #.
There is a new Config parser, that just drop the first line, and take
the file as ini.

Pros:
	1. The format is read friendly, like all the ini files.
Contra:
	1. Since is a php file, the common editor should provide a correct
interface for edit files, but since the ini structure is not PHP, maybe
the user have ugly messages in the editor.
	2. If you want to access directly to the file
http://p6/configuration.php => you will get a parser error. Maybe is not
a contra, but is ugly.

--- About 2. ---
Here i want to discuss some scenarios.
First, the zip or the tarball, provide a folder phprojekt with all the
files and folders in it.
Currently the structure is:
phprojekt/
	application/
	htdocs/
	library/
	logs/
	tmp/
	upload/
	configuration.ini
And the limitation say that a vhost must be set to the htdocs folder.

With the private folder, the idea is something like:

phprojekt/
	application/
	htdocs/
	library/
	configuration.ini
private/
	logs/
	tmp/
	upload/

Scenario 1 - Common German structure:
	If i drop the phprojekt folder in my public_html, then i have:
public_html/
	phprojekt/
		application/
		htdocs/
		library/
		configuration.ini
And the link to the API is http://my.domain/phprojekt/htdocs/index.php
In this scenario, the setup routine can try to create a private folder
in 2 places:
	1. in the same level as phprojekt.
		Pros: The setup should can, since is a public folder with full access
to the web server.
		Contra: Even if the private folder have a random name set by the user,
is accessible by web http://my.domain/private.
For solve that, we provide a .htaccess with Deny from all, but the
folder is still writable and public.
The user can set the write rights for this folder to "only owner"?, yes,
but ONLY in Linux, in Windows system, the folder is public and writable
(only the admin of the system can set the rights there).

	2. Outside the public_html:
		Pros: Is not accessible by Web.
		Contra:
			- The web user in general don't have access to write folders there,
or for rights or for groups limitation. If the setup routine can't
create the folder, the user/admin must do it.
If there are many problem for the common users to create a vhost, you
think that create a folder outside public is easy for them?
			- If the folder is created, must have the correct right access, since
the API don't have right for change them, and again, the access system
works only for Linux, in windows is ALL 777. Do you think that the user
can do it?

Scenario 2 - Personal systems:
	In general, for the Scenario 1, we can use the DOCUMENT_ROOT var for
get the public folder, but for example, i have a windows system with
apache and the document root set on for example D:www, then i have many
sub folders for many pages.
	My DOCUMENT_ROOT, is www, and the API will try to create a folder in:
	- D:/www/phprojekt (in the same level as phprojekt)
	- or in D: (Outside the public folder)

Add to all this, if the server use safe_mode = ON, the API have problems
to access this private folder, depend on where is it.

Also, if the rule is "no writable folders in the public one", what we
can do whit the application folder?.
Yes, we can make it read only, and add a private/application/ where the
user can add new modules.
But then the user can't delete the current modules like "Calendar" if he
don't want it in the system.
Also, we must change the routines that scan the application folder for
new modules, or custom ones, and we will have TWO applications folders,
one for the system and one for the users...if this don't generate
misunderstandings...

For finish, i am agree with a private folder where we can write stuff in
a safe way, but reading the post, and the comments, there are many
"normal users" playing with P6, and are not "administrators", so maybe
this folder will provide more problems than solutions to these users.

What do you think?

If you want to test a bit, one of these implementations is in:
 - http://github.com/gsolt/PHProjekt/tree/privateFolder
Works fine in windows, since don't try to set access, in Linux i tried
to install it in the MF server, and neither the API or myself, can
create a private folder with 0600 access in the before public_html.

Greetings,
Gustavo

Re: [Phprojekt-devel] Private folder on P6

[Albrecht G. <alb...@ma...>]

Hi Gustavo, hi David,

Gustavo, thank you for the scetch of the possible solution on the
".htaccess" issue.

David: can you please check this and give feedback to Gustavo?
It is pretty urgent, since this is the last point we have to integrate
beofre the release of 6.0.2

thank you and all the best
Albrecht

>  since many people complain about the "DocumentRoot" limitation in the
> installation of PHProjekt 6, for a better solution about the security,
> there is an idea about to make 2 improves:
> 
> 1. Make the configuration.ini file, a php file, so nobody can read it,
> only the web server can execute it or read it.
> 
> 2. Make a private folder for save there the logs, the temporally and the
> uploaded files. (All the files written by the API/User).
> 
> --- About 1. ---
> The best solution that i found, is to keep the configuration.ini file as
> format, add a <?php in the first line, rename it to configuration.php
> and change the comments from ; to #.
> There is a new Config parser, that just drop the first line, and take
> the file as ini.
> 
> Pros:
> 	1. The format is read friendly, like all the ini files.
> Contra:
> 	1. Since is a php file, the common editor should provide a correct
> interface for edit files, but since the ini structure is not PHP, maybe
> the user have ugly messages in the editor.
> 	2. If you want to access directly to the file
> http://p6/configuration.php => you will get a parser error. Maybe is not
> a contra, but is ugly.
> 
> --- About 2. ---
> Here i want to discuss some scenarios.
> First, the zip or the tarball, provide a folder phprojekt with all the
> files and folders in it.
> Currently the structure is:
> phprojekt/
> 	application/
> 	htdocs/
> 	library/
> 	logs/
> 	tmp/
> 	upload/
> 	configuration.ini
> And the limitation say that a vhost must be set to the htdocs folder.
> 
> With the private folder, the idea is something like:
> 
> phprojekt/
> 	application/
> 	htdocs/
> 	library/
> 	configuration.ini
> private/
> 	logs/
> 	tmp/
> 	upload/
> 
> Scenario 1 - Common German structure:
> 	If i drop the phprojekt folder in my public_html, then i have:
> public_html/
> 	phprojekt/
> 		application/
> 		htdocs/
> 		library/
> 		configuration.ini
> And the link to the API is http://my.domain/phprojekt/htdocs/index.php
> In this scenario, the setup routine can try to create a private folder
> in 2 places:
> 	1. in the same level as phprojekt.
> 		Pros: The setup should can, since is a public folder with full access
> to the web server.
> 		Contra: Even if the private folder have a random name set by the user,
> is accessible by web http://my.domain/private.
> For solve that, we provide a .htaccess with Deny from all, but the
> folder is still writable and public.
> The user can set the write rights for this folder to "only owner"?, yes,
> but ONLY in Linux, in Windows system, the folder is public and writable
> (only the admin of the system can set the rights there).
> 
> 	2. Outside the public_html:
> 		Pros: Is not accessible by Web.
> 		Contra:
> 			- The web user in general don't have access to write folders there,
> or for rights or for groups limitation. If the setup routine can't
> create the folder, the user/admin must do it.
> If there are many problem for the common users to create a vhost, you
> think that create a folder outside public is easy for them?
> 			- If the folder is created, must have the correct right access, since
> the API don't have right for change them, and again, the access system
> works only for Linux, in windows is ALL 777. Do you think that the user
> can do it?
> 
> Scenario 2 - Personal systems:
> 	In general, for the Scenario 1, we can use the DOCUMENT_ROOT var for
> get the public folder, but for example, i have a windows system with
> apache and the document root set on for example D:www, then i have many
> sub folders for many pages.
> 	My DOCUMENT_ROOT, is www, and the API will try to create a folder in:
> 	- D:/www/phprojekt (in the same level as phprojekt)
> 	- or in D: (Outside the public folder)
> 
> Add to all this, if the server use safe_mode = ON, the API have problems
> to access this private folder, depend on where is it.
> 
> Also, if the rule is "no writable folders in the public one", what we
> can do whit the application folder?.
> Yes, we can make it read only, and add a private/application/ where the
> user can add new modules.
> But then the user can't delete the current modules like "Calendar" if he
> don't want it in the system.
> Also, we must change the routines that scan the application folder for
> new modules, or custom ones, and we will have TWO applications folders,
> one for the system and one for the users...if this don't generate
> misunderstandings...
> 
> For finish, i am agree with a private folder where we can write stuff in
> a safe way, but reading the post, and the comments, there are many
> "normal users" playing with P6, and are not "administrators", so maybe
> this folder will provide more problems than solutions to these users.
> 
> What do you think?
> 
> If you want to test a bit, one of these implementations is in:
>  - http://github.com/gsolt/PHProjekt/tree/privateFolder
> Works fine in windows, since don't try to set access, in Linux i tried
> to install it in the MF server, and neither the API or myself, can
> create a private folder with 0600 access in the before public_html.
> 
> Greetings,
> Gustavo
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Phprojekt-devel mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phprojekt-devel

Re: [Phprojekt-devel] Private folder on P6

[David S. P. <ds...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Gustavo

Am 27.04.10 03:48, schrieb Gustavo Solt:
> Hi all,
>  since many people complain about the "DocumentRoot" limitation in the
> installation of PHProjekt 6, for a better solution about the security,
> there is an idea about to make 2 improves:
> 
> 1. Make the configuration.ini file, a php file, so nobody can read it,
> only the web server can execute it or read it.
> 
> 2. Make a private folder for save there the logs, the temporally and the
> uploaded files. (All the files written by the API/User).
> 
> --- About 1. ---
> The best solution that i found, is to keep the configuration.ini file as
> format, add a <?php in the first line, rename it to configuration.php
> and change the comments from ; to #.
> There is a new Config parser, that just drop the first line, and take
> the file as ini.
> 
> Pros:
> 	1. The format is read friendly, like all the ini files.
> Contra:
> 	1. Since is a php file, the common editor should provide a correct
> interface for edit files, but since the ini structure is not PHP, maybe
> the user have ugly messages in the editor.
> 	2. If you want to access directly to the file
> http://p6/configuration.php => you will get a parser error. Maybe is not
> a contra, but is ugly.

Yes the solution might work, but still other files might be accessable,
things like README, tests, VERSION and so on.

> --- About 2. ---
> Here i want to discuss some scenarios.
> First, the zip or the tarball, provide a folder phprojekt with all the
> files and folders in it.
> Currently the structure is:
> phprojekt/
> 	application/
> 	htdocs/
> 	library/
> 	logs/
> 	tmp/
> 	upload/
> 	configuration.ini
> And the limitation say that a vhost must be set to the htdocs folder.
> 
> With the private folder, the idea is something like:
> 
> phprojekt/
> 	application/
> 	htdocs/
> 	library/
> 	configuration.ini
> private/
> 	logs/
> 	tmp/
> 	upload/

I like the approach, but I think it gets difficult, as PHProjekt looks
different on disk depending on the way you set it up. In fact using the
private folder method we can separate htdocs and the rest, as the rest
doesn't need to be access from the outside and that's what we care about.

> 		Contra: Even if the private folder have a random name set by the user,
> is accessible by web http://my.domain/private.
> For solve that, we provide a .htaccess with Deny from all, but the
> folder is still writable and public.
> The user can set the write rights for this folder to "only owner"?, yes,
> but ONLY in Linux, in Windows system, the folder is public and writable
> (only the admin of the system can set the rights there).
No write access cannot be by owner only, most webhosts user a group for
the webserver and different owners, in that case the webserver will not
be able to write to the directory.

> 
> 	2. Outside the public_html:

we cannot do this, as this is particularly what people that just have a
usual web host, complain about. They just have webspace that is
accessable from the outside.

> 		Pros: Is not accessible by Web.
> 		Contra:
> 			- The web user in general don't have access to write folders there,
> or for rights or for groups limitation. If the setup routine can't
> create the folder, the user/admin must do it.
> If there are many problem for the common users to create a vhost, you
> think that create a folder outside public is easy for them?
> 			- If the folder is created, must have the correct right access, since
> the API don't have right for change them, and again, the access system
> works only for Linux, in windows is ALL 777. Do you think that the user
> can do it?

My suggestions is the following:

  We add .htaccess files to the phprojekt/ folder and to
  phprojekt/htdocs. The .htaccess in phprojekt/ forbids
  access. This is done by putting the following into the
  .htaccess file:

      deny from all

  and in htdocs/.htaccess:

      allow from all

  This way we keep our setup the way it is, we just have
  to remove the check for the vhost. Well not remove, we
  should state a message that says:

  Please note that your webserver needs to support .htaccess
  files to deny access to the configuration files. Running
  PHProjekt 6 without using the provided .htaccess files
  to deny access to certain files and folders, might not
  be secure and is not recommended.

  This is still not a perfect solution as we do rely on
  .htaccess (apache only) and that the webserver is configured
  to allow access overwriting. So Apache might be configured
  to use .htaccess but not to allow forbidding access using .htaccess.

  But I personally think 90% of the users have a setup that will
  work with what I suggested, while it keeps our changes low and
  the code base stable.

David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJL1vmlAAoJEAT0aMuPE7Z1dr8P/ibs3PsgD49+j8WlEgtruAMr
FLM0hf8J+tSvUOwhkxrfcLUtMQRNpL066R1fTgI9XuLQoycIN3Qoed27/wkvsTOM
21RZRUBejVEz0TsxoUr6DP2glpCkC59hApQ2GkMl8TvTUMit8a1e8d+3CysKsjUB
1kxuQL0qoKLEp2FczaqkbBRGi5WclMGUbmINYAo+23NQz3eZyFPi7wLhxbVj8T7d
W0ikjh/eV7NMNSVEuThlBObnBrvhhTnIcp3KuEaCm448UOy070dOgFOGpFpoKbDS
s81IGwm/P+eT3WbrRLwwfcaA4K+lhQS6SHkBxhx93tnS4z7xVm1MsY8jdqBH06jj
WEsScyHfqnJNW4yJiXlRqvCg8v5Ll1lWRAOLPLMXxPo54or/iXH2165RuPzXp3li
dduxZDF7JNuc/L/TLLhKXwW7zNR7u1kXP/R9cAD9fnGKpmx0eK7UmvVycPTUzRLh
oVzv347JbukP6ZUguOOnfcf3AkBHRfvH26Sit6fcwB5JL7yB043FuFvcqUP6zPNs
K0N/EwpBuDZx310v6l/WgGpfzJ7yBk5Q37eoOhbsB0gtaN6/5ixUb2eEP4sGfU0K
nqU8MSsveFVZ1SiNKa3DBRvGr/gw+BVLFoFSG6Rvpo+/dNUER/iu6XWyb5HRiS6e
UbH26YuWVxo1Q1zKS9dc
=q8wZ
-----END PGP SIGNATURE-----

Re: [Phprojekt-devel] Private folder on P6

[Gustavo S. <gus...@gm...>]

Hi all,

 David's suggestion implemented.

http://github.com/gsolt/PHProjekt/commit/93ee227fd5bc8b29a396da120646504ece27b963

Greetings.

On 27/04/2010 01:50 p.m., David Soria Parra wrote:
> Hi Gustavo
> 
> Am 27.04.10 03:48, schrieb Gustavo Solt:
>> Hi all,
>>  since many people complain about the "DocumentRoot" limitation in the
>> installation of PHProjekt 6, for a better solution about the security,
>> there is an idea about to make 2 improves:
> 
>> 1. Make the configuration.ini file, a php file, so nobody can read it,
>> only the web server can execute it or read it.
> 
>> 2. Make a private folder for save there the logs, the temporally and the
>> uploaded files. (All the files written by the API/User).
> 
>> --- About 1. ---
>> The best solution that i found, is to keep the configuration.ini file as
>> format, add a <?php in the first line, rename it to configuration.php
>> and change the comments from ; to #.
>> There is a new Config parser, that just drop the first line, and take
>> the file as ini.
> 
>> Pros:
>> 	1. The format is read friendly, like all the ini files.
>> Contra:
>> 	1. Since is a php file, the common editor should provide a correct
>> interface for edit files, but since the ini structure is not PHP, maybe
>> the user have ugly messages in the editor.
>> 	2. If you want to access directly to the file
>> http://p6/configuration.php => you will get a parser error. Maybe is not
>> a contra, but is ugly.
> 
> Yes the solution might work, but still other files might be accessable,
> things like README, tests, VERSION and so on.
> 
>> --- About 2. ---
>> Here i want to discuss some scenarios.
>> First, the zip or the tarball, provide a folder phprojekt with all the
>> files and folders in it.
>> Currently the structure is:
>> phprojekt/
>> 	application/
>> 	htdocs/
>> 	library/
>> 	logs/
>> 	tmp/
>> 	upload/
>> 	configuration.ini
>> And the limitation say that a vhost must be set to the htdocs folder.
> 
>> With the private folder, the idea is something like:
> 
>> phprojekt/
>> 	application/
>> 	htdocs/
>> 	library/
>> 	configuration.ini
>> private/
>> 	logs/
>> 	tmp/
>> 	upload/
> 
> I like the approach, but I think it gets difficult, as PHProjekt looks
> different on disk depending on the way you set it up. In fact using the
> private folder method we can separate htdocs and the rest, as the rest
> doesn't need to be access from the outside and that's what we care about.
> 
>> 		Contra: Even if the private folder have a random name set by the user,
>> is accessible by web http://my.domain/private.
>> For solve that, we provide a .htaccess with Deny from all, but the
>> folder is still writable and public.
>> The user can set the write rights for this folder to "only owner"?, yes,
>> but ONLY in Linux, in Windows system, the folder is public and writable
>> (only the admin of the system can set the rights there).
> No write access cannot be by owner only, most webhosts user a group for
> the webserver and different owners, in that case the webserver will not
> be able to write to the directory.
> 
> 
>> 	2. Outside the public_html:
> 
> we cannot do this, as this is particularly what people that just have a
> usual web host, complain about. They just have webspace that is
> accessable from the outside.
> 
>> 		Pros: Is not accessible by Web.
>> 		Contra:
>> 			- The web user in general don't have access to write folders there,
>> or for rights or for groups limitation. If the setup routine can't
>> create the folder, the user/admin must do it.
>> If there are many problem for the common users to create a vhost, you
>> think that create a folder outside public is easy for them?
>> 			- If the folder is created, must have the correct right access, since
>> the API don't have right for change them, and again, the access system
>> works only for Linux, in windows is ALL 777. Do you think that the user
>> can do it?
> 
> My suggestions is the following:
> 
>   We add .htaccess files to the phprojekt/ folder and to
>   phprojekt/htdocs. The .htaccess in phprojekt/ forbids
>   access. This is done by putting the following into the
>   .htaccess file:
> 
>       deny from all
> 
>   and in htdocs/.htaccess:
> 
>       allow from all
> 
>   This way we keep our setup the way it is, we just have
>   to remove the check for the vhost. Well not remove, we
>   should state a message that says:
> 
>   Please note that your webserver needs to support .htaccess
>   files to deny access to the configuration files. Running
>   PHProjekt 6 without using the provided .htaccess files
>   to deny access to certain files and folders, might not
>   be secure and is not recommended.
> 
>   This is still not a perfect solution as we do rely on
>   .htaccess (apache only) and that the webserver is configured
>   to allow access overwriting. So Apache might be configured
>   to use .htaccess but not to allow forbidding access using .htaccess.
> 
>   But I personally think 90% of the users have a setup that will
>   work with what I suggested, while it keeps our changes low and
>   the code base stable.
> 
> David