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]

Same Problem

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]

Easy now...

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
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.