
06-28-2009, 06:20 AM
|
|
Junior Guru
|
|
Join Date: Mar 2002
Posts: 232
|
|
Joomla install - best way to solve directory permission issues?
I installed Joomla today, and it went smoothly except that under Help -> System Info in the Joomla admin panel, all "Directory Permissions" are "Unwritable."
I've read up on various solutions, such as installing suphp to take care of user permissions. But if I have my own Linux VPS and I am the only user (i.e. noone else has accounts on my VPS), what is the easiest way to fix this issue? Can I just CHMOD those directories to 777 without worrying about causing a security issue? Or is there a similarly easy solution for someone like me with very basic Linux knowledge?
|

06-28-2009, 06:22 AM
|
|
Community Liaison
|
|
Join Date: Mar 2003
Posts: 8,056
|
|
Moved > Technical & Security Issues.
__________________
JoneSolutions.Com - Your Number One Choice On The Net - since 2001
----------------------------------------------------------------------------------------
Linux Shared and Reseller Hosting * KVM Fully Managed cPanel VPS * Super Special Servers
USA/EU cPanel Fully Managed Servers * cPanel Server Management * R1Soft/Idera Backup
|

06-28-2009, 09:41 AM
|
|
WHT Addict
|
|
Join Date: Mar 2004
Location: Chennai India
Posts: 114
|
|
Check the file ownership, that may be the problem becasue chmod 777 will fix the issue normally.
|

06-28-2009, 07:56 PM
|
|
Intangible Asset Appraiser
|
|
Join Date: Mar 2009
Location: Austin Tx
Posts: 1,952
|
|
777 is not the best idea, you just want write, as write+execute on the web user is a deadly combo.
If the web user is the owner of the dir, 644 is a good place to start.
__________________
This is the best signature in the world....Tribute!
(It is not the best signature in the world, no. This is just a tribute)
|

06-28-2009, 11:16 PM
|
|
WHT Addict
|
|
Join Date: Mar 2004
Location: Chennai India
Posts: 114
|
|
In that case just change the owner as apache and change the mode as 644
|

06-29-2009, 12:08 AM
|
|
WHT Addict
|
|
Join Date: Mar 2007
Location: Chennai, India
Posts: 132
|
|
You don't need to worry about directory permissions as long as you have correct FTP mode enabled.
Note: Some components will not work properly under FTP mode so make sure you don't use one of them.
__________________
Cheers,
Sivanandhan, P. (a.k.a. apsivam)
My Blog Site
|

06-29-2009, 01:24 AM
|
|
Temporarily Suspended
|
|
Join Date: Jun 2009
Posts: 117
|
|
Hello ,
I dont agree with 777 permissions its insecure and the best best is to given 775 permissions.This resolves issues in Joomla since it gives permissions for both user and group to write
|

06-29-2009, 01:35 AM
|
|
Intangible Asset Appraiser
|
|
Join Date: Mar 2009
Location: Austin Tx
Posts: 1,952
|
|
Quote:
Originally Posted by linux-engineer
Hello ,
I dont agree with 777 permissions its insecure and the best best is to given 775 permissions.This resolves issues in Joomla since it gives permissions for both user and group to write
|
Actually, that would depend on who owns the dir...if owner / group is apache, and it's set 775, then owner / group still have "7" rwx, all other have "5", so it may as well be 777.
the owner/group need write, no execute, however you slice it, to be somewhat more secure.
the ftp mode, as apsivam said, works, but that can sometimes be a little above some users heads, the the cavets it can bring.
__________________
This is the best signature in the world....Tribute!
(It is not the best signature in the world, no. This is just a tribute)
|

06-29-2009, 02:06 AM
|
|
Community Liaison 2.0
|
|
Join Date: Feb 2005
Location: Australia
Posts: 5,118
|
|
Quote:
Originally Posted by kreativ
Can I just CHMOD those directories to 777 without worrying about causing a security issue?
|
Yes. If you're the only user on the system then you're safer running PHP as the apache user and opening up access to upload directories as needed. That way an attacker has access to write only those directories and read only your web directories. By contrast if you run PHP suexec then any exploit in your application will give the attacker full access to everything in your account. To make things more secure you should also prevent execution of PHP and CGI scripts in the upload directories.
Quote:
|
Or is there a similarly easy solution for someone like me with very basic Linux knowledge?
|
Alternatively if it makes you feel better (not having directories with 777 permissions) you can chown them to the apache user (usually "apache" or "nobody", depending on your system) and use standard 755 permissions. As mugo suggests, it amounts to much the same thing.
__________________
Chris
"Learn from the mistakes of others. You can never live long enough to make them all yourself." - Groucho Marx
|

06-29-2009, 02:23 AM
|
|
Intangible Asset Appraiser
|
|
Join Date: Mar 2009
Location: Austin Tx
Posts: 1,952
|
|
A little file security knowledge needs to show here...if the user is apache, then setting the first bit to 7 is rwx, so you've given away the farm.
the three number (777) correspond to user/group/all-other positions.
if the upload dir is as so:
drwxr-xr-x 2 apache.apache 4096 Apr 23 00:28 uploads
(user / group both owned by apache)
if the perms are 7xx or x7x, then you may has well have 777, because apache has rwx on the user and group positions.
if user.owner is apache.apache, then make it 664
if is root.apache then 764
(nobody may be substituted for apache, depends on the user/group set in your httpd.conf)
It does not matter about multiusers on the system itself, as we are talking about the apache public httpd process user here. What's in /home just doesn't matter.
What does matter is the user/group coming in through apache processes, and the access given to that user.
__________________
This is the best signature in the world....Tribute!
(It is not the best signature in the world, no. This is just a tribute)
|

06-29-2009, 02:46 AM
|
|
Community Liaison 2.0
|
|
Join Date: Feb 2005
Location: Australia
Posts: 5,118
|
|
Quote:
Originally Posted by mugo
if the user is apache, then setting the first bit to 7 is rwx, so you've given away the farm.
|
I'm not sure what point you're trying to make here, but suppose the system is running PHP suexec, and the directory is owned user:user with permissions 755 (probably the most common shared-hosting situation). Then PHP runs as user, user's permission (first bit) is rwx and again you've "given away the farm". But in this situation you've also given away read-write to everything under /home/user (including mail, .htaccess files etc.)
Giving apache permission to write to a directory is only a problem if it can be exploited by other users on the same system. With no other users this is a non-issue.
__________________
Chris
"Learn from the mistakes of others. You can never live long enough to make them all yourself." - Groucho Marx
|

06-29-2009, 03:11 AM
|
|
Intangible Asset Appraiser
|
|
Join Date: Mar 2009
Location: Austin Tx
Posts: 1,952
|
|
Quote:
Originally Posted by foobic
I'm not sure what point you're trying to make here, but suppose the system is running PHP suexec, and the directory is owned user:user with permissions 755 (probably the most common shared-hosting situation). Then PHP runs as user, user's permission (first bit) is rwx and again you've "given away the farm". But in this situation you've also given away read-write to everything under /home/user (including mail, .htaccess files etc.)
Giving apache permission to write to a directory is only a problem if it can be exploited by other users on the same system. With no other users this is a non-issue.
|
He's not running suexec, only "read up on it".
755 is the "most common", unfortunately. If it's root.root, cool, if httpd user, then oh oh. Not really the best security.
There are certain dirs under joomla dir that OP needs write by apache, that is all we are really aiming for here.
Somehow all the "experts" are probably just confusing the poor guy.
Just to get stright to the point...to finish the Joomla setup so you can upload images, templates, plugins, etc.
web user and / or group needs write to
administrator/components/
components/
images/
images/banners/
images/stories/
modules/
tmp/ (this if for uploading templates, plugins, etc)
Other than this, if you try to upload something, Joomla will give a warning to you as to which dir it can't access, just set the perms the same on that dir at that time, off you go.
__________________
This is the best signature in the world....Tribute!
(It is not the best signature in the world, no. This is just a tribute)
|

06-30-2009, 01:43 AM
|
|
Junior Guru
|
|
Join Date: Mar 2002
Posts: 232
|
|
Thanks for all the feedback.
Admittedly, I'm still a little confused.
I'm the sole user on the VPS, so I don't need to protect those Joomla directories from other users on the VPS. I just need to protect them from the outside world.
I know I can always fall back on the FTP layer (that's how I completed Joomla setup), but would rather not have to worry about some components not working with it.
So if I'm reading correctly, 777 is a security risk even if I'm the only one with access to the VPS.
Would uploading the Joomla files as root user (so the directories are root:root instead of user:user) make any difference?
Or could someone perhaps just give me what command line entries I should use to allow those specific directories to be writable by Joomla while minimizing the impact on security?
For example, something like the below was one method I came across when Google searching on the matter. Don't know whether it's the best way though...
Code:
chgrp apache administrator/components
chmod g+w administrator/components
|

06-30-2009, 01:54 AM
|
|
Intangible Asset Appraiser
|
|
Join Date: Mar 2009
Location: Austin Tx
Posts: 1,952
|
|
Exactly.
I was following you on that, and my answers were indeed geared toward the web user, not a system user (as most VPSs are used...)
Since "root.root" owns theses, you can set them as 776 and not have to mess with the owner.group
just get in a directory above the one you want to change and do a
chmod -R 776 ./directoryname
(notice the . in front of the / - this is important, it means "from here", not base root of your machine)
this means
Change mode, recursively, on ./directoryname, giving user root rwx (7), group root rwx (7), all others rw (6) (apache or web user falls under "all others").
do this for each of the dirs i named in my last post.
So long as you don't have a public user with w+x (write / execute) you are relatively safe.
(no upload/write + execute script)
You can also just do these one at a time, as you need to open access.
If you are only going to upload templates, just do the /tmp, for instance.
No need to open up what you are not going to use.
If you need help, PM me, we'll get some faster comm going 
__________________
This is the best signature in the world....Tribute!
(It is not the best signature in the world, no. This is just a tribute)
|

06-30-2009, 02:15 AM
|
|
Community Liaison 2.0
|
|
Join Date: Feb 2005
Location: Australia
Posts: 5,118
|
|
Quote:
Originally Posted by mugo
chmod -R 776 ./directoryname
|
chmod -R has the unfortunate side-effect of changing files as well as directories - not what you want here. The directories need the execute bit set, the files don't, so really the commands to do this should be:
Code:
find directoryname -type d -exec chmod 777 {} \;
find directoryname -type f -exec chmod 666 {} \;
But in any case (other than suexec) the apache user needs access to certain directories. The easiest option is simply (as user) to set those directories 777. People constantly parrot out "OMG 777 is dangerous" but again all you are doing is exposing those directories to other users on the system. With no other users it's not a problem.
__________________
Chris
"Learn from the mistakes of others. You can never live long enough to make them all yourself." - Groucho Marx
|
| Thread Tools |
Search this Thread |
|
|
|
| Display Modes |
Linear Mode
|
| Postbit Selector |
|
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
|
|
|
| Login: |
|
|
| Advertisement: |
|
|
| Web Hosting News: |
|
|
|