This is being transfered from the Install help forum. I started out there, but i think this is better suited here.
I've since re-installed Gallery2 5 or 6 times now trying different things. One big problem i see with the gallery: Administration! Maybe i don't understand fully how gallery works or is supposed to work. But i would think that a site admin would want to be the admin for multi-user galleries. Or should i install and let the user be the admin.
Problem i see with that is that, the user can now specify where to import files from, and if by some mistake they were to import say /etc/ that might cause a severe security problem.
So if there is supposed to be one admin for the multi-user galleries, it would be better to centralize the administration so that the admin could login and see all the galleries and move through them and make changes.
Maybe the easiest thing would be to limit what an admin can do if they are not the installer. Maybe during the install process, the import dir can be specified or not.
I'm still a bit worried about file permissions and accidental file importing from a wrong location. Esp. if /home/user/importdir/symlink = /etc
don’t know if this can happen. guess i should try a few more things to break my beater server!!!
Sorry i can't be of much help to write code for these features, my time is pretty well used up on opencores (FPGA programmer/embedded systems). If i have a few spare hours, i'll dig through the code
Posts: 32509
please add a link to the other topic, i won't answer the same questions twice. and other users might want to know the whole context of the discussion.
Posts: 8
http://gallery.menalto.com/node/40249
Posts: 8
Anyone reading this should look at using open_basedir (carefully)
<NOTE>
If one uses the open_basedir as described below, Gallery fails. It fails because it tries to open a file that does not exist, and therefore php5 imposes the open_basedir restriction. Maintainers need to look at /g2data/cache/module/core/0/0/0.inc with open_basedir set to "/g2data"
The correct actions is to check for file existence, then create the file (touch) then open the file, yeah, i know that sucks, but talk to PHP about why open_basedir restricts file operations in an allowed dir
I don’t know the validity of this problem before php-5.0.5, have not tested that yet.
Additionally read Bug #35301 and Bug #30188.
</NOTE>
The correct usage of open_base dir can be found here: http://www.php.net/manual/en/security.apache.php look at the post from daniel dot eckl at gmx dot de on 08-Aug-2002 07:16
This problem is not just a Gallery issue but can be found in any web application that allows users to access files on the local server. Therefore, Gallery should not be at fault, however, Gallery should post a warning during the install process that open_basedir is set to "/". Because Gallery allows users to import files from the local file system, Gallery should inform the user of the possible threat this could cause. There should also be a reference to the use of open_basedir in the docs for limiting where users can import files. A search of the docs for open_basedir showed no results exact in the FAQ, which was more or less an error due to incorrect use of open_basedir.
This is what i've tried in my virtualhost and non-virtualhost configurations.
Notes about how system is setup:
1) /pub is a symlink to /mnt/sdc1/pub1 <-- For a quick change of things this works okay, point symlink to test pub dirs as required
2) Codebase is located in /pub/webfiles <-- Not directly accessible by apache, alias directive or symlinks can be used to allow apache access to required codebase directories
3) /home is a symlink to /mnt/sdc1/home <-- same as note 1
4) php5 installed in /usr/local/php5, php4 installed in /usr/local/php4 <-- symlink usr/local/php to which version i want to play with
<Location />
php_admin_value open_basedir "/mnt/sdc1/pub/www/:/usr/local/php/lib/:/mnt/sdc1/pub/webfiles/:/mnt/sdc1/home/"
</Location>
This seems to work for users that access their page by www.mydomainnamehere.tld/~auser
Apache does not seem to expand the ~ in the path names in the above.
For users that access their page by auser.mydomainnamehere.tld or www.auser.tld
<Location />
php_admin_value open_basedir "/usr/local/php/lib/:/mnt/sdc1/pub/webfiles/:/mnt/sdc1/home/auser/"
</Location>
This seems to work in the respective virtualhosts
valiant, I would consider this a valid precaution for anyone running gallery, do you have any other suggestions?
NOTE: This was being tested on a test server so some dirs are non-standard and with fresh installs of apache & php and several types of user dirs and virtualhosts.
I would say most system admins know of and how to use open_basedir, but for Jon Q Admin that runs a home server this could cuase him/her some grief.
Posts: 8
Here is part of my apache logs
[Sun Nov 20 09:58:58 2005] [error] [client ip.a.d.r] PHP Warning: Smarty::fetch() [<a href='function.fetch'>function.fetch</a>]: open_basedir restriction in effect. File(/home/bgshea/g2data/smarty/templates_c/%%2062586582/%%51^512^512C2C3E%%error.tpl.php) is not within the allowed path(s): (/mnt/sdc1/pub/www/:/usr/local/php-5.0.5/lib/:/mnt/sdc1/home/:/mnt/sdc1/pub/webfiles/) in /mnt/sdc1/pub/webfiles/gallery2/lib/smarty/Smarty.class.php on line 1251, referer: http://www.notaulr.tld/~bgshea/gallery/main.php?g2_view=core.ItemAdmin&g2_subView=core.ItemAdd&g2_itemId=7&g2_return=http%3A%2F%2Fwww.notaurl.tld%2F%7Ebgshea%2Fgallery%2Fmain.php&g2_returnName=album
[Sun Nov 20 09:58:58 2005] [error] [client ip.a.d.r] PHP Warning: Smarty::fetch(/home/bgshea/g2data/smarty/templates_c/%%2062586582/%%51^512^512C2C3E%%error.tpl.php) [<a href='function.fetch'>function.fetch</a>]: failed to open stream: Operation not permitted in /mnt/sdc1/pub/webfiles/gallery2/lib/smarty/Smarty.class.php on line 1251, referer: http://www.notaulr.tld/~bgshea/gallery/main.php?g2_view=core.ItemAdmin&g2_subView=core.ItemAdd&g2_itemId=7&g2_return=http%3A%2F%2Fwww.notaurl.tld%2F%7Ebgshea%2Fgallery%2Fmain.php&g2_returnName=album
[Sun Nov 20 09:58:58 2005] [error] [client ip.a.d.r] PHP Warning: Smarty::fetch() [<a href='function.include'>function.include</a>]: Failed opening '/home/bgshea/g2data/smarty/templates_c/%%2062586582/%%51^512^512C2C3E%%error.tpl.php' for inclusion (include_path='.:/usr/local/php-5.0.5/lib/php') in /mnt/sdc1/pub/webfiles/gallery2/lib/smarty/Smarty.class.php on line 1251, referer: http://www.notaulr.tld/~bgshea/gallery/main.php?g2_view=core.ItemAdmin&g2_subView=core.ItemAdd&g2_itemId=7&g2_return=http%3A%2F%2Fwww.notaurl.tldg%2F%7Ebgshea%2Fgallery%2Fmain.php&g2_returnName=album
Thses error occur because the file does not exist.
May not be the 0.inc file causing the problem, but certainly needs to be looked at.
There error are hindering the use of open_basedir.
Posts: 32509
@open_basedir note:
i've just added
http://codex.gallery2.org/index.php/Gallery2:How_to_configure_open_basedir_for_G2
http://codex.gallery2.org/index.php/Gallery2:Known_Issues#Known_Issues
thanks for reporting.
if you patch the GalleryPlatform classes, please submit it to us.
Posts: 8
I did some more testing, and I am unable to create ANY file when open_basedir is used (safe_mode = off). Here is a test php script i used:
<?php
$file = fopen("/home/bgshea/tempfile.inc", "r+");
if( $file )
echo "Sucess.";
else
echo "Failure.";
fclose( $file );
touch("/home/bgshea/tempfile.inc");
$file = fopen("/home/bgshea/tempfile.inc", "x+");
if( $file) {
fprintf($file, "Hello World!");
$fclose( $file );
} else
echo "Failure.";
readfile("/home/bgshea/tempfile.inc" );
?>
php outputs Failure twice. I have few other posts on php related sites looking for a solution. If/when i find one i'll make note of it. Hopefully soon!!
For the time being, i have removed the open_basedir setting from my vhosts and hope that no one tries anything funny.
At this point i beleive the problem to be with PHP and not Gallery.
Thanks,
BTW it should be noted if i have not done so: I'm running Apache 2.0.54 and PHP-5.0.5.
Posts: 32509
and if you do a touch before fopen?
fopen is the same as copy in respect to this problem. the file doesn't exist yet so it can't resolve the symlink thus it's detected to be outside the open_basedir.