Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Allowing clients ftp access or file uploads on a shared server could lead to scripts being run which can scan directories and files outside the clients web root.

What can you do to stop this given that we don't have much control over the environment? Even the individual client ftp accounts create files with the same user and group.

In our case we have shared hosting on a linux machine running apache with php.

share|improve this question
up vote 2 down vote accepted

By the sounds of it, you are using a single hosting account to allow FTP uploads for multiple clients? If this is the case then you really need to move to some sort of reseller account where you can segregate users and give them their own FTP accounts, to upload to their own FTP areas, that have no interaction with other users.

If I've misunderstand and you do have some sort of multi account reseller account, you need to talk to your host (or just move hosts) as they have not got things set-up properly.

share|improve this answer
Hmm, I'm confused by what you mean by single hosting account and the multi reseller. We have a single account but hand out individual ftp accounts. Its just that the files end up with the same user and group ids so we can't use file permissions for locking out. My thinking is that apache/php should know (thru some config) the directory limits because for each domain we have to set the root directory. Am I wrong with that simple idea? – zaf Mar 14 '11 at 13:52
@zaf does your account allow you to create seperate accounts for your users, with their own domains and logins? Or do you just have your own single domain account, that you are creating FTP users for? – Sam Mar 14 '11 at 14:01
@Sam the latter but I can create domains/emails/ftp users. – zaf Mar 14 '11 at 16:41
@zaf, ok but these users are all still part of your account, they are not segregated. It's like giving your family members front door keys, they are all different keys but they get you in the same place. Upgrade your account to a reseller one and get proper segregation, get everyone their own house. – Sam Mar 14 '11 at 16:56
@Sam aha - so thats whats going on. my provider does not have a reseller option. I have to get a dedicated server instead. thanks for the explanations. – zaf Mar 15 '11 at 9:25

This is VERY WRONG. Look for another host if you don't have the rights to get things locked down yourself.

The scripts within each website should run in their own user context, and should not have read or write access to the directories of any of the other virtual hosts on that server. Usually this same user context will protect people from each other when accessing the server via FTP.

For shared hosting, system administrators need to be very careful about the processes executed by the server as by default they'll run in the same context as the web server. suEXEC can be configured to run CGIs in different user context, and fastCGI can be used for PHP - but it's not the default way things run.

share|improve this answer
I've checked and scripts in one 'domain' can access others in OUR account. I don't want to check other accounts for fear of jail time. – zaf Mar 14 '11 at 13:53
I may have misunderstood. If your account does not allow you to create multiple websites (i.e. on different domains) for different customers, then it can't be used in the way you're describing. – Steve Mayne Mar 14 '11 at 14:12
@Steven Mayne the accounts allows creating new domains/emails/ftp users. The usual pro shared hosting. – zaf Mar 14 '11 at 16:42
Ah, but if they're considered "add on domains" these all have the same access rights. As suggested above, you're going to have to get a reseller account (or buy multiple hosting packages) if you want domain segregation. – Steve Mayne Mar 14 '11 at 21:02
thanks for the info. – zaf Mar 15 '11 at 9:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.