Joomla 1.0.11 Installation

[amaru21]

Has anyone successfully installed Joomla 1.0.11 on Plesk 8? I have several clients that want to use it and I need to try to get it installed ASAP.

When I go through the installation it says everything is Unwriteable under the "Directory and File Permissions Check:"

The files/directories are writeable by the owner of the files (not apache). I assume they're not writeable because PHP files are not processed by suexec?

Does anyone have any guidance on getting Joomla setup successfully (and securely) or getting PHPsuexec working properly?

[phoenixisp]

I host quite a few Joomla 1.0.11 sites on a Plesk box with CentOS4.3. You have to use your ftp client (or use SSH) and chmod the files listed as unwritable to writable. That means the directories much be set at 777 and the files (such as configuration.php) to 666.

[amaru21]

Thanks for the response. I was hoping for a more secure solution without having to make the directories world-writeable. I would think that PHPsuexec would be a better solution, but I'm having trouble getting it working.

[Who-m3]

One of my clients was testing Joomla 1.0.11 out a few days ago. His only problem, during installation, was a chmod for one file (the configuration file). Otherwise, everything was operating with no problems. Perhaps showing us some of the output from the install would help us help you...

[amaru21]

Going through the installation it has -

Directory and File Permission Check:

administrator/backups/ Unwriteable
administrator/components/ Unwriteable
administrator/modules/ Unwriteable
administrator/templates/ Unwriteable
cache/ Unwriteable
components/ Unwriteable
images/ Unwriteable
images/banners/ Unwriteable
images/stories/ Unwriteable
language/ Unwriteable
mambots/ Unwriteable
mambots/content/ Unwriteable
mambots/editors/ Unwriteable
mambots/editors-xtd/ Unwriteable
mambots/search/ Unwriteable
mambots/system/ Unwriteable
media/ Unwriteable
modules/ Unwriteable
templates/ Unwriteable

Of course this can be fixed by chmod'ing these to 777. However, I don't like having directories on my server that anyone can access.

[oddconcept]

I am having the same problems Installing.
Using 777, is not an option for me for security reasons.

I got everything to install by setting it to 777 and then changed it back. But I still get write errors.

I have read several places about suexec. I don't really understand how it works. Correct me if I am wrong it will allow apache to run as group "psacln" therefore allowing the 750 permissions should work.

Can someone please shed some light on this for me. Or is this not the way to go? Is there a better solution?

Thanks for any help anyone can provide.

[amaru21]

I'm not an suexec expert, but I think it's the right way to go. Suexec allows the web server to run CGI's as the UID that owns the script. I believe that PHP files can use suexec if PHP is running in CGI mode rather than a module for Apache.

[oddconcept]

thanks amaru21.

Please Excuse my ignorance....

Does running php in "CGI Mode" loose any functionality that it would have with apache.... Or does that even make any sence???? :)

Thanks for the Help

[amaru21]

I think there may be a performance loss when using it as a CGI binary. I'd be willing to give up a little performance if it meant improved security.

Someone correct me if I'm wrong on any of this.

[carliebentley]

I'm a Joomla fanatic.

Your biggest security risks with the Latest version of Joomla are with modules that allow the users to upload files.

In order for the files to be uploaded it'll have to write them to the /tmp directory at the root level of the server, even if it's only temporary while it waits to write it to the final destination directory.

This opens a huge security hole but it is easily avoided by ensuring the /tmp directory is mounted as noexec.

As for chmodding the required folders for the installation and operation of Joomla, those folders are all safe. There isn't anything that can be placed in them which would cause a problem with the security of the site.

You also have to watch out for anything that uses xmlrpc, Joomla it's self doesn't use xmlrpc, but 3rd party modules like Remository, and several photo galleries use it to allow photo uploads.

Other than those things, there is one other concern to consider. Don't install a 3rd part SEF component, to rewrite all the URLs to search engine friendly urls.

Many of the 3rd party SEF rewrite engines use the MySQL server to rewrite the URLs and if you get into a situation with certain calendar modules, search engines will attempt to index every day from 1901 to 2060, and you MySQL server will eat up 99.9% of your CPU cycles.

I wouldn't worry about the world write on the folders un Joomla, they stay on top of the security pretty well.

Oh and before I forget, USE the .htaccess file supplied with the newest version of Joomla, as well as the globals.php file. These two things will really secure your Joomla installs.

[amaru21]

So are you saying to chmod the installation folders to 777 and then change them back after the installation?

I just found another solution that may work:
http://forum.swsoft.com/showthread.php?s=&threadid=34270&highlight=suphp

I may try this later today and see what breaks/works.

[carliebentley]

Originally posted by amaru21
[B]So are you saying to chmod the installation folders to 777 and then change them back after the installation?


Nope, I'm saying follow the installation proceedures when you run the "install" script.

Set permissions on the folders it lists to 0777, and leave them.

The folders that need to be 777 are safe. I have a couple dozen 1.0.11 sites running and have had plenty of hacking/exploit attemtps, but none of them have been successful against the new version of Joomla.

Hacking attempts against wordpress, phpads, and b2evolution have been successful, so I dropped all of the Plesk Application Vault Packages, and only use the latest versions of these packages.

[amaru21]

Having the directories set to 0777 is a security risk. I have set those Joomla directories to 0777. I then create a simple PHP script within another virtual site on the same server. In that PHP file I can put commands that have full access to those directories. I can delete/create/modify files with no problems. This is a huge security risk if you ask me.

[carliebentley]

Originally posted by amaru21
Having the directories set to 0777 is a security risk. I have set those Joomla directories to 0777. I then create a simple PHP script within another virtual site on the same server. In that PHP file I can put commands that have full access to those directories. I can delete/create/modify files with no problems. This is a huge security risk if you ask me.

First, you have to know how to do that, second you have to have access to another virtual site on the server.

I have to tell you, that if you have someone else that has access to another virtual site on your server, and they hack a Joomla install(or any other PHP script) on one of your sites, that's very easy to take care of. You simply identify them and have them arrested.

Personally, I have to also add that I have several clients, and resellers on a server I own and control. If I found one of my clients or resellers was atttempting to hack/exploit another site on the server that doesn't belong to them, I would not hesitate to file charges.

Now, if this is a matter where you are a reseller on someone elses server that has multiple other resellers, the responsibility falls back to the server owner to prevent this kind of idiotic hacking attempt. It's easily monitored, and quickly tracked back to the point of origin.

If you are renting space on someone elses server and only have one or two domains, you probably shouldn't be interested in attempting to run Joomla.

The latest version of Joomla is far more secure even with folders set to 777 than the application vault install of Mambo.

And Joomla will run if you set those folders back to 555, you just can't install modules, or make certain other changes.

Believe me, I'm very concerned about security, but it's easy to go overboard with Joomla and break it. The new version has a very nice .htaccess file and the ability to turn off register_globals, so a lot of this is no longer a concern.

[oddconcept]

Thanks for everyones help. I got everything working now. However, I have a security question.

What would happen if I add the apache user to the "spacln" group? (Just Curious)

My server only runs a couple of my personal web-sites.
I do not have shared hosting. I have total control of my box.

Thanks again.

[carliebentley]

Originally posted by oddconcept
Thanks for everyones help. I got everything working now. However, I have a security question.

What would happen if I add the apache user to the "spacln" group? (Just Curious)

My server only runs a couple of my personal web-sites.
I do not have shared hosting. I have total control of my box.

Thanks again.

Interesting, but I think apache is already part of a wheel group that has a high level of privleges, however, adding it to the psacln group is an interesting idea. I'll have to play with this.

Hmm, it would affect the ownership, but I wonder how it would react. I suppose if you took it out of all other groups, and only had it in the psacln, that might pose a problem with the administration panel, because some of the administration functions are root/admin level. I think the web-stats are always owned by root, not apache.

Interesting.

[oddconcept]

WOW that was quick...
Thanks for the quick reply.

Another question... What other groups does the apache user sopose to belong to?

[carliebentley]

Generally Apache is it's own group. You'll notice files created by apache if you do:

ls -la

will show up as apache:apache

Now often it's in the same top level group as root:root, but that's probably not a good thing at all.

You probably don't want apache in any group that has any kind of capability outside the /home/httpd/vhosts/ folder.

Really, apache should be able to read and write to the /tmp directory but should not have the ability to execute any files.

[oddconcept]

Thank you carliebentley, you have been truly helpful.

That is weird my apache user is under apache and psaserv.
apache : apache psaserv

Is that normal? What should it be? only apache? :(

[carliebentley]

Originally posted by oddconcept
Thank you carliebentley, you have been truly helpful.

That is weird my apache user is under apache and psaserv.
apache : apache psaserv

Is that normal? What should it be? only apache? :(

Well, it could be the way plesk was installed. I assume you're running Plesk 8.0.1 I think psaserv is a group in which the Plesk admin user, and the various other servers run.

[oddconcept]

Yes I am using plesk 8.0

Thanks for all your help.
Please let me know if you find out any more information about adding apache to spacln.

Thanks again for all your help.

[AWD__]

I need to know how to make the /tmp directory writeable. I'm running Plesk 8.0.1 and am installing Joomla 1.0.11. The install page continues to show the session save path of /tmp as unwriteable.

Here's what I've done so far.

chmod 666 /tmp so everyone will read and write but no exec. This is verified by ls -las:
8 drw-rw-rw- 4 root root tmp

Any info will be appreciated,

Michael

[carliebentley]

Originally posted by AWD__
I need to know how to make the /tmp directory writeable. I'm running Plesk 8.0.1 and am installing Joomla 1.0.11. The install page continues to show the session save path of /tmp as unwriteable.

Here's what I've done so far.

chmod 666 /tmp so everyone will read and write but no exec. This is verified by ls -las:
8 drw-rw-rw- 4 root root tmp

Any info will be appreciated,

Michael

I had this same problem, and it's not a matter of makeing the permissions 0666 on the /tmp directory.

In order for the /tmp directory to be useable, and have the noexec flag, it has to be mounted (like a drive) as a seperate partition with noexec commands.

There are many tutorials on here to walk you through the process.

Do a search for tmp noexec and see if this helps with your situation.

[AWD__]

I discovered a relationship between the safe mode setting in php.ini and the session save path (at least using the /tmp dir.) Hopefully this will be helpful if it's not already in the forum.

I had created the hosting for the domain I'm installing Joomla on via the domain template in Plesk. When creating a domain template the option to have safe mode off (unchecked) is not there. I was unaware the option becomes available at the time of hosting set up and by default it's checked in the services section. It's easy to skip over the fact that safe mode will be On for a domain even though you may have turned safe mode Off in php.ini.

With safe mode Off in php.ini and safe mode On in Plesk settings for domain hosting settings, the session save path directory was not writeable. So, I turned safe mode On in the php.ini file and Off in Plesk domain hosting settings and discovered the session save path is now writeable. I don't know if that will always be the case if someone chooses a different path in the php.ini settings, but if you use /tmp, you won't need to mount it as a separate drive to get it writeable. You could run safe mode Off globally and have it unchecked in the domain hosting settings, but if you don't have to open it up globally, then I wouldn't.

Hope this helps...

Joomla rules!

[carliebentley]

I haven't found a reason to be concerned with what Joomla writes to the /tmp directory.

Mostly it's just session data, so the tmp directory doesn't have to be a noexec mounted partition, but, if there is more than one site on your server, there may be other scripts on there that could allow someone to upload a perl script to the tmp directory and execute it.

[CritiKill]

I have a new Plesk 8 installation on my server. I've created a domain (set PHP to not run in safe mode) and FTP'ed the Joomla installation files to the domain's httpdocs folder. When I try to run the Joomla web installer, I get all the folders are unwriteable and so is the PHP sessions path.

Does anybody have a solution for this that does not involve chmodding 777 or PHPSUEXEC or anything too fancy. All I would like to do is to run a few Joomla installs without breaking out in cold sweats every time. This problem is costing me lots of time and money and I would REALLY like if somebody could help me get some kind of solution to this.

I like the suggestion of putting the domain ftp user into the Apache group or something, does anybody know if that is a viable, workable solution? Also, what is the command syntax to actually do this?

I am appalled that Plesk does'nt work out of the box with something as commonplace as Joomla.

[carliebentley]

Your problem really isn't revolving around some deficiency of Plesk. In fact, Plesk and the wonderful Filemanager system makes installing Joomla a breeze.

Chmodding the folders to 0777 is actually pretty easy, and is only required to install Joomla. Once Joomla is installed it's possible to set most of those folders back to 0644 or some other more secure setting.

Personally I leave the folders at 0777, because of the security built into Joomla, there's a slim chance that those folders could be exploited.

Granted, it's not the most secure situation, but I've used other scripts that are no where near as secure and thanks to XMLRPC (which isn't in Joomla), those scripts are very exploitable.

I've had no problems running Joomla on nearly all of my sites even leaving the folders set to 0777.

Yes, I know it's possible to exploit a folder on a site set to 0777, but it's not easy and there's not that much that can be done with it.

I wouldn't blame plesk, because you are afraid of setting your folders to 0777. You can always set them to 0777, install Joomla, and then change them back. However you could break Joomla by setting the permissions too low.

[dyrer]

Warning: is_writable() [function.is-writable]: open_basedir restriction in effect. File(/var/lib/php/session) is not within the allowed path(s): (/var/www/vhosts/domain.com/httpdocs:/tmp) in /var/www/vhosts/domain.com/httpdocs/main/includes/joomla.php on line 2012
Unwriteable
Any way to fix that

[carliebentley]

Is there any reason you're attempting to write your session data to, "(/var/lib/php/session)"?

On my plesk server with RHEL4 on it, I make certain that Joomla! knows to put the session data in the /tmp directory, which on my server has been converted to a mounted partition that does not allow execution.

Also, it would help to know the particular version of Joomla!.

But once again, this doesn't look like a problem with Plesk, but looks like a problem with your Joomla! installation.