Yup, positive on the recursive chmod. As for the include error, are you getting this when you do a fresh install using the SSH commands I posted above?
Not tested, this is the 3rd install which has the include_path problems, so i think this would be the same even with your commands… but i’ll test it out. it depends on the phpversion(5.2.5) and the default setting of the include_path i think.
I did get Magento Connect to work. I first altered the permissions using my ftp software (IPswitch) and everything looked fine but connect didnt’ work. I then accessed using Putty (shell access) and used thechmod command and no problem at all after that.
I guess it was an issue with ipswitch for some reason.
I guess it was an issue with ipswitch for some reason.
I don’t believe FTP software has the ability to recursively chmod a directory, which is why SSH worked but your FTP program did not. Typically when you set the permissions for a folder or file in an FTP program, it does it only on the folder and/or files selected, but it won’t set the permissionsfor all the files in a directory unless you manually go through them all.
I tried it with the root store directory set to 777, but I didn’t go through and set every file and subdir to 777, only those specified. I just couldn’t stomach the thought of everything on the server being vulnerable like that.
I’m not sure about ownership...I have a VPS though, so I have shell access if there’s a way to check.
I tried it with the root store directory set to 777, but I didn’t go through and set every file and subdir to 777, only those specified. I just couldn’t stomach the thought of everything on the server being vulnerable like that.
I’m not sure about ownership...I have a VPS though, so I have shell access if there’s a way to check.
I’m not sure where you’re seeing a list of files/directories that need to be set, but you need to do a recursive chmod on the root directory:
chmod -R 777 magento
To see the ownership, just do a directory listing:
ll
It will output something similar to the attached. The username on that account is magento.
Yes and no. If you’re only running Magento, then you really don’t have much to worry about. If you’re running other things in the same directory as Magento, then yes, there are security risks.
For example, if you’re putting magento in your root directory and you have, say, WordPress or other applications running in that directory too, there’s a security risk.
If you have Magento in a sub-directory, like magento or shop or whatever, and you only chmod recursively the magento directory, no issues.
To my knowledge, this is the only way to get the extensions section to work. So until Magento comes up with another way of doing this, there’s not much else you can do (unless someone knows of a way to get around this of course, then by all means post).
As for changing ownership, I believe you’re talking about setting the ownership to apache, nobody, or daemon. The problem with that is, what’s the difference between doing that and setting all the files to 777? Anything accessible to the user apache is accessible in the same way setting your permissions to 777 is (basically). On top of that, you’ll run into issues everytime you want to modify or delete a file, you’ll have to ask your host to do it or login as root to remove/modify something.
Just to confirm, setting the directory /public_html/magento and EVERY file and subdir under it to 777 is not going to pose a security risk to either the store or any of the other installed apps?
Just to confirm, setting the directory /public_html/magento and EVERY file and subdir under it to 777 is not going to pose a security risk to either the store or any of the other installed apps?
No, not necessarily. Anytime you are using software on the Internet there is a security risk - what we can do is mitigate the risk.
Having a modified wordpress install on your store account is not good. Same thing for PHPBB - both of these softwares have a known history of insecurities and to think you could run these apps in ‘any’ ecommerce environment wouldn’t be too smart. Rarely does smarts have anything to do with it, though - it’s all about the financial angle.
Put Magento in a subdomain called ‘store.yourdomain.com’ if you’re even the littlest bit concerned about your security - this will mitigate a great deal of issues right off the bat.
The second thing to do would be to re evaluate your ecommerce needs. Not everyone should be running Magento and it is has not been developed to run in every environment.
The simple fact that you would consider running PHPBB in the same space as you’re storing clients credit card and personal data raises some serious ethical issues far beyond the security issues you’ve pointed out. If you were truly concerned about security you would not be in shared hosting in the first place, as we all know you are really only secure as your weakest neighbor, right?
I have a VPS, and it was verified to meet all Magento requirements.
I won’t be storing CC info either - using PayPal checkout.
I have no earthly idea why running a Wiki, forum, auction, and online store from the same domain poses an ethical problem.
So basically, my options are:
1) Get rid of 70% of my site’s content so I can do something like download a Magento theme
2) Give 777 permission to everything in /store
3) Put Magento on a subdomain and leave everything else as is
None of those are good options...one of the team members talked about changing ownership so that file permissions didn’t have to be changed. I emailed him about how to do this but haven’t gotten a response.
None of those are good options...one of the team members talked about changing ownership so that file permissions didn’t have to be changed. I emailed him about how to do this but haven’t gotten a response.
The response is to change the ownership of the files to the user your webserver runs as.
That is the point of this thread - the web server, or the user the web server runs as, must have write access to every file under Magento - This may be the user ‘nobody’, ‘apache’, or whatever - the point is that this is really no different than running your files with 777 chmod. There’s maybe a slight mitigation in exploit in a shared hosting environment, however this would be quickly outweighed by the inability to manage your own files.
I guess it depends on the angle of the attack you are trying to mitigate - if it is a local attack from a shared hosting neighbor by passing the web server software, or an attack using the web server software.
This isnt really unique to Magento at all, the same is true for any software in which you can add an image to (read upload product image) - each of the products you are running on your site are FAR FAR more insecure than Magento - So, I really dont understand what all the fuss is about. Just curious as to why the subdomain idea doesnt work for you? This is usually a very good solution and I am interested in your reasoning.
...or while we wait for this to be corrected:
Change Magento/ to 777, do what you need in Magento Connect, then change the directory/files back to the recommended security.
NathanJ: Option 4) Put Magento into it’s own dedicated VPS and keep known security risks elsewhere.
Having a modified wordpress install on your store account is not good. Same thing for PHPBB - both of these softwares have a known history of insecurities and to think you could run these apps in ‘any’ ecommerce environment wouldn’t be too smart.
Though you may be using Paypal checkout, you still will have a database of all of your customer email addresses, mailing addresses, telephone numbers. With known liabilities such as PHPBB and Wordpress, it wouldn’t be much of a stretch for a hacker to add a few new lines of code into your Magento, and have it start asking your customers to verify their credit card information. Even if all they did was get your customers’ email addresses, they could send emails out in your name asking for them to verify their information, etc. Crucial Web Host was just trying to say that in a far more efficient manner than I just had to.
As for this issue, sure it’s fixable. The Magento crew is a bit busy at the moment, so a little patience is in order.
