User permissions differ in upload troug joomla, DA and FTP

P

Prlwytzkofski

New member
Joined
Aug 13, 2006
Messages
1
I encounter the following problem. Files uploaded trough DA or FTP can be edited by both DA and FTP. But files installed trough Joomla (or any other cms I presume) can not be changed by FTP or DA

Assume I install some additional software for Joomla, using Joomla's own installing feature, and want to ad an translated language file, i can not upload it trough FTP or DA. Just for that one file to upload i need to create a 'package' (including some xml) that joomla understands.

Looking at owner of the files, the ones placed by Joomla are owned by apache, the ones uploaded trough DA or FTP are owned by the user.



Ed.
 
This is normal because apache is the one creating the files when the CMS creates them. Maybe a better way to say it is that the CMS (Joomla) uses apache to create the files so apache owns it. You are expected most of the time to use the CMS to edit those files.

You can set joomla to set permissions so that the user and group have write prevs.
 
You can set joomla to set permissions so that the user and group have write prevs.
Click to expand...
There's an add-on for Joomla that allows you to do all that though I've forgotten the name at the minute.

BUT - be very careful with permissions in Joomla. Some folders have to be CHMOD'd to 777 during installation, at least for some of the add-on components. It's not uncommon for people to leave these at 777 and leave themselves wide open to hackers by doing so.

In fact I believe this is the main reason quite a few Joomla sites get hacked. Folders should be CHMOD'd to 755, and files to 644. Anything left at 777 is asking for trouble.
 
This is a royale pain in the ass. I waiste about 30 minutes every day, just changing owners for new files add with joomla.

I'm talking about the joomla that comes with Installatron, a popular plugin that makes Directadmin attractive.

We need a solution for this. It would save us time, headaches, problems, and irate customers.

Cheers :)
 
It shouldn't affect security; it's a special case which will be built into the File Manager which will make sure you're only allowed to change files owned by apache in your own directories.

Note that the feature, as written, will only allow the files to be deleted. Perhaps you should contact DA support and ask them if it'll do what you want.

We've created a cronjob that runs every minute for everyone using Joomla or Mambo who asks for it, to change the files to their own username; you'd be surprised how little server resources it uses.

Jeff
 
Ok, well, only being able to delete it won't solve the problem. The real problem is, which I thought was being addressed, is that the mods with apache owner and group are not working correctly or at all.

jlasman said:
you'd be surprised how little server resources it uses.

Jeff
Click to expand...

You'd be surprised how happy I would be if you shared your cron masterpiece with me :)
 
Last edited:
I would not arbitrarily chmod files to 777. You may not want them to execute. chmod 766 is better. Allows read/write but not execute.

Command to run:
Code: 
nice -n 19 find /home -user apache -exec chmod 766 {} \;
 
766 still allows the world to write to your files and I think is a bit insecure.

Here's an example cron job in the root cron file:
Code: 
*/10 * * * * chown -R ezwebus:ezwebus /home/ezwebus/domains/ezwebusa.com/public_html/*
It will change the file ownership for all files and directories created by joomla/mambo, etc., every ten minutes.

To run it every minute:
Code: 
* * * * * chown -R ezwebus:ezwebus /home/ezwebus/domains/ezwebusa.com/public_html/*

To run it every minute with nice:
Code: 
** * * * nice -n 19 chown -R ezwebus:ezwebus /home/ezwebus/domains/ezwebusa.com/public_html/*

Pay no attention to the site in browser
... attribution here.
Click to expand...
Jeff
 
766 still allows the world to write to your files and I think is a bit insecure.
Click to expand...

Of course that is true. But if you change owners and the files are not 766 then the php scripts that created the files to begin with now cannot edit or delete them. Depending on what scripts are being run that could be a problem as well.

The best way of course would be to run the php scripts as the owner and not apache.
 
It works for our Joomla clients for over a year now.

That's good enough for me :) .

Jeff
 
Ok, sounds pretty simple, but I suppose this would have to be created for each user individually, correct?

Nice script, but is this something we can protest about to joomla or DA to avoid these work arounds ? I'm guessing it's Joomla script's fault but I'm not sure how these scripts work.
 
toniramos said:
Ok, sounds pretty simple, but I suppose this would have to be created for each user individually, correct?
Click to expand...
Yes.
but is this something we can protest about to joomla or DA to avoid these work arounds ?
Click to expand...
Sure. But it won't get you anywhere.
I'm guessing it's Joomla script's fault but I'm not sure how these scripts work.
Click to expand...
It's not anyone's fault. It's the way the Linux security model works. If a file or directory is created by anyone other than root, then the creating user cannot change it's ownership. When a Joomla user creates a file/directory through Joomla, it's actually created by the apache user and there's no way to change it.

One way to fix it would be for the server to write all files as 666 and all directories as 777, but then anyone in the world could change anything on the server.

Or perhaps have all files owned by user and by a special joomla group, and give write/modification rights to that special group. But then you'd have to set that up for the entire server, and that would create lots of security issues for the whole server as well.

Joomla itself isn't terribly secure, but to do what it does, it's probably as secure as it can get.

The best security comes from the model DA uses, where if a file/directory is created by Joomla it has to be managed by Joomla.

Jeff
 
I was running into this same issue when I got Joomla installed for a client of mine. It turns out I actually had a few issues. One issue was that Installatron changed some of the directory permissions to 707, instead of 777. So, I manually fixed those. The second issue, which is described in this thread, is where anything uploaded through Joomla gets owned by apache instead of the user.

I liked Jeff's idea of creating a cron job to run periodically to change the owner/group on the files/directories for each user using:

Code: 
chown -R user:user /home/user/domains/domain.com/public_html/*

However, instead of setting up a separate cron job for each user, I decided to write a dynamic script that would do it for all users. What do you all think of this approach?

Code: 
#!/bin/bash
 
homedir=/home
 
for users in $homedir/*; do
    user=${users:6}
    if [ -d $users ]; then
        domainsdir=$users/domains
        if [ -d $domainsdir ]; then
            for domains in $domainsdir/*; do
                htmldir=$domains/public_html
                if [ -d $htmldir ]; then
                    chown -R $user:$user $htmldir/*
                fi
            done
        fi
    fi
done

Does anyone see any problems with my code or any issues with doing it this way? Thanks.
 
You need to be careful doing that for all files for all users. Some users may have php scripts that create files and also modify them on a regular basis. If you change the owners of the files and don't chmod the formally apache owned files to 766 then you just broke some of your users scripts as mentioned above. If might work fine for most CMS scripts but what about user written scripts that you do not know about?
 
I only do it if customers have a continuing problem.

I think if you install suphp is will write the files as the user. At least that was my understanding. And I think the new customapache script that smtalk wrote will install suphp for you. I have not tried it yet.
 
I have not tried the new customapache build script yet. I'm waiting until all of the issues are resolved before using it. I'll probably wait until the first final release is out and some documentation has been written on the proper ways to use it.

Thanks for your help. I may just create a text file that lists the users that have this issue and should have the owner changed on the files, then read the file in with my script to update the ownership. I'd rather do this than maintain a bunch of different cron jobs for each user. I can share the changes if anyone is interested. Thanks.
 
You must log in or register to reply here.
Back
Top