Quick Bash question for a hosting company

webjive · 11-29-2011, 01:25 PM

Hey guys/gals, first time here and after searching the forums, I didn't quite find the answer I was looking for.

My question is this... I have a small hosting company and we run primarily PHP scripts with Apache and phpSuExec. I have noticed that a lot of clients are FTP'ng files up and not setting the proper permissions (644 for most files and 755 for dirs) and I would like to run a nightly cron script to fix this automatically.

What I want the script to do is scan all /home/xxx/public_html dirs and run the following commands:

Code:

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;

Thoughts?

Thanks!!!!!

_bsd · 11-29-2011, 01:59 PM

Instead you can set the default umask for the ftp daemon

depending on the distro and which ftp daemon is being used.

Here's an example from one of our systems

cat /etc/ftpd.conf
umask real 072

or you can edit /etc/inetd.conf
ftp stream tcp nowait root /path2yourDeamon/ftpd ftpd -u 007

Read up on umasks and Unix permissioning to get the appropriate umask

tronayne · 11-29-2011, 02:07 PM

All you really have to is something like this:

Code:

#!/bin/bash                                                                                                                   
#
#       scan for public directories, change mode of all
#       files and subdirectories
#
for DIR in $(find /home -type d -name 'public')
do
        cd $(DIR)
        find . -type d -exec chmod 755 {} \;
        find . -type f -exec chmod 644 {} \;
done

Hope this helps some.

[EDIT]
Or, duh!, do what @bsd suggest!

Cripes.
[/EDIT]

webjive · 11-29-2011, 02:10 PM

@tronayne.. Thanks! I think I can take it from here. This along with the excellent suggestion on the FTP config, we should be able to lock things down tighter...

webjive · 11-29-2011, 02:35 PM

@bsd, just checked our pro-ftp server config and our umask is at 133:022 so, that would put files at 644 and directories at 755. Our challenge is users FTP'ing files have their FTP apps to set permissions after upload because we're finding php files set to 755.. ouch..

Hence the need for the script...

_bsd · 11-29-2011, 03:19 PM

Don't know about that, you can fix this in a script, but users explicitly changing perms after upload? Sounds fishy to me.

I have a shared hosting acct I can upload to but, I use scp, not ftp, ftp passes passwords in cleartext.
Sounds like you might want to educate your users as well as write a script.

User tronayne's commands will fix the perms if that's the route you have to take for now.

webjive · 11-29-2011, 03:23 PM

Not so much fishy as ignorant to the consequences.. I have one client in particular who has a noob doing FTP and I constantly find that file permissions are often incorrect after they upload changes which sometimes means they have the wrong file/dir permissions (on upload) set incorrectly.

_bsd · 11-29-2011, 06:01 PM

Again, depending on the ftpd, certain commands can be removed.
Disallow chmod if possible

webjive · 11-29-2011, 08:09 PM

@bsd.. Thx.. I'll look into proftp and see if I can dis-allow ch-modding above certain levels.

d3vrandom · 11-30-2011, 09:04 PM

If you do this you are going to break A LOT OF your user's websites. Most popular content management systems like wordpress, drupal and even vbulletin used on this very site require 777 permissions on certain files and folders. And yes there are millions of websites out there that use these CMS and work just fine. So you are wrong to think that writeable permissions are the cause of your security holes. You need to look into things like php suexec if you want greater security. Again, if you change permissions en masse you will be inundated with support tickets!

sneakyimp · 12-01-2011, 04:23 AM

I agree that it's *very* bad to go changing file permissions -- what if someone has set up a log file writable by apache? Lots of CMSes require write permission on a directory or file here and there. And, on the other hand, they may want to exclude access from certain files for privacy reasons.

webjive · 12-01-2011, 07:49 AM

It's not a very bad idea. We have a closed hosting environment (no general hosting) and the server is specifically tuned for Joomla so, apache log files are not being written to the users /home/public_html. Its a standard cPanel environment with quite a bit of extra security software installed.

So, for those needing to FTP files, 644 and 755 for files/dirs is all they need.

Setting all the file and dir permissions on all /home/xxx/public_html accounts is the right thing to do because some of my clients did accidentally set their index.php file to 755 and some robo hacks caught that and pushed up a hack that overwrote just that one file. That's how they got in.

d3vrandom · 12-01-2011, 06:44 PM

Quote:

Originally Posted by webjive

It's not a very bad idea. We have a closed hosting environment (no general hosting) and the server is specifically tuned for Joomla so, apache log files are not being written to the users /home/public_html. Its a standard cPanel environment with quite a bit of extra security software installed.

So, for those needing to FTP files, 644 and 755 for files/dirs is all they need.

Setting all the file and dir permissions on all /home/xxx/public_html accounts is the right thing to do because some of my clients did accidentally set their index.php file to 755 and some robo hacks caught that and pushed up a hack that overwrote just that one file. That's how they got in.

Try uploading something using joomla. Add an image to a page or something. Then you'll see how you screwed up

BTW I can tell you right now what your problem is and it isn't' permissions. It's most likely because you are using an outdated version of joomla. Joomla, like most popular open source CMS, gets targeted by bots a lot so you have to keep it up to date.

sneakyimp · 12-01-2011, 06:47 PM

Quote:

Originally Posted by d3vrandom

Try uploading something using joomla. Add an image to a page or something. Then you'll see how you screwed up

Unless I'm mistaken, suExec will cause apache to run as whatever user owns the website rather than as www-data or apache or nobody or whatever apache usually runs as. This should generally permit a Joomla install to write whatever it needs to.

I still think changing a user's file permissions is a bad idea though.