files, folders attributes proplem, help plz

[htonline]

Hi
I have some proplems with atttributes of files and folders .
On my vps, I download joomla from joomla.org and unzip it via ssh (root), so the owner of files and folders is root .
chown -R hehehe httpdocs *

I use above command to change file owner to hehehe (this is ftp account I have created for domain hehehe.com) , but when I install some modules or components via joomla control panel, new folders and files created have owner is "apache" , so I can not upload (overwrite) that files and folders, I must login to root and set attributes for those files and folders again (hehehe) . What is the proplem ?

I use a shared hosting before and all files, folders uploaded, installed via joomla control panel have only 1 user owner .

also on shared hosting I can set attributes for files is: 600 or 644 but joomla still can save configuration file, but on my VPS I must set attribute for file is 666, and for security I must set attribute again 644 or 604 .

How can I make everything easy as on shared host before ???

Thanks for your help
sorry about my english

BR

[JPC-Zishan]

I use above command to change file owner to hehehe (this is ftp account I have created for domain hehehe.com) , but when I install some modules or components via joomla control panel, new folders and files created have owner is "apache" , so I can not upload (overwrite) that files and folders, I must login to root and set attributes for those files and folders again (hehehe) . What is the proplem ?

Your VPS is running PHP as an Apache module. When PHP runs as an Apache module then all php scripts run under the ownership of Apache user i.e "apache" on your VPS. All those files/folders that need to be modified by Joomla should be owned by Apache user so that they can be modified. The solution to this problem is switch to PHP as CGI but it depends that whether the control panel your VPS is running officially supports PHP as CGI or not.

[htonline]

thanks for your reply, it's clear

[Gwaihir]

Yeah, if that option is open to you, PHP-CGI is the nicest way out of this. Shared hosting at JagPC does run PHP in CGI mode.

Zishan: could you share which of the available control panels don't support PHP as CGI?

[JPC-Zishan]

Zishan: could you share which of the available control panels don't support PHP as CGI?

Plesk and InterWorx do not officially support PHP as CGI yet. DirectAdmin has recently started supporting PHP as CGI. New Plesk versions use the OS provided PHP rpms to setup PHP where the older Plesk versions were having PHP setup through own (Swsoft) rpms. As now they are using OS provided RPMs so might need to wait till the RPMs are available with the OS. InterWorx forum does have few threads in which couple of users tried custom rpms to setup PHP as CGI and it works fine for most of them. But its still not yet integrated officially with InterWorx itself.

[jason]

I've set up PHP to run as CGI on my Inteworx VPS because I wanted to run both PHP4 and 5 concurrently. To do it I compiled PHP5 and suPHP from source. It wasn't hard to do (although I have 10+ experience in running Linux) and it works great. I posted a tutorial about it. If you decide to do it, though, keep in mind that this is not supported by Interworx and therefore should be considered "experimental."

Note that since the tutorial was posted both PHP and suPHP have released new versions. The process to build them shouldn't have changed, however. Also note that, despite what I said in the tutorial, dropping php.ini files into a script's directory works fine. I still prefer the suPHP_ConfigPath approach, however, because that will apply the php.ini file to an entire subtree, not just a single directory.

--Jason

[htonline]

Hi all
thanks for reply, I have one more question .
if my file chmod is 666, so is it unsecure ??? public can write ?? what it mean ??
anybody from the world can see and edit that file ???

thanks
ht

[jason]

chmod 666 means that anyone with access to the server filesystem has full rights to the file. If usera has a file with chmod 666, userb could log in to the server, poke around usera's home directory (assuming users aren't chrooted/jailshelled, which is a whole different discussion), find that file, read it, modify it, or delete it.

When going through the web it is a little different because the web server will generally only serve files from certain locations (public_html) and there isn't an easy way to manipulate files directly through unauthenticated http. IF THE FILE IS IN public_html IT CAN STILL BE READ BY THE WORLD, so you should always keep files with sensitive information outside of public_html. If you or someone else on the server is running a piece of software like a blog or forum and a bug in that software gets exploited, very often it becomes possible for the attacker to get direct access to the filesystem and if that happens then he'll be able to see and manipulate that file through the web.

chmod 666 files are never a good idea, but unless you are running in a suexec environment (where PHP scripts are run under their owner's UID instead of the web server's UID, as discussed above) there is often no way around them.

--Jason