Siteworx account might crash the HTTPD server : FTP default config

NodeWorx General Discussion
1

Hello,

We have too much clients whom complain their web sites doesn’t work.

9/10 times it is because they have deleted the content of /home/account/ and put there all their web pages. It happens even if we send them instructions on how to and where to upload their web pages. I’m pretty sure you know how some of them are. They don’t read instructions.

When we explain them why it happens the answer is always the same : “well I thought I was in my webspace, and so I thought I could do what I’d like without break anything”

It is not a huge pbm, it not happens every days, and when it happens there is only this client that is impacted.

There is a much more important pbm to this kind of issue (the default path of ftp).

They are also able to rename the var directory. See this other thread

If they do this, then the HTTPD server can’t restart, because it doesn’t find the errors log file.
This case is much more bad as it impacts every body on the box.

So could it be possible to have by default the /home/*/var dir no rename able ?

Personaly we do not see yet the need to have as default ftp path the /home/account dir (maybe there is good reasons to this, but we can’t figure out which one, maybe the backups…)

We think it should be better to have a FTP DEFAULT PATH config, for all siteworx accounts, set to /home/account/public_html rahter than /home/account

Like this all siteworx accounts could never break their document_root and best, they never could crash the HTTPD restart process by renaming the var dir.

To conclude :

  • Is it possible to set the default FTP path for to the public_html symlink (or document_root). This default conf resolve all these issues

  • If not (why?) would it be at least possible to non allow, BY DEFAULT, a user to rename the var dir ?

Hope this contrib will help to improve the overall security in nodeworx

Pascal

2

I dont think it is good to go direct to public_html because you would still want access to private (no http) areas for example an “include” directory.

I think maybe /home/account/account.com/ would work better and prevent the var access.

3

I agree with you.

It is fine to have a space out the document_root. even in itself it doesn’t change sonething. If you web page access this dir, then all can access it via http protocol. So for me there is no security gain to have an include folder off the docroot.

The most important is the user can’t rename the VAR dir.

I’m not so concern by the user that scratch his docroot. We always could tell him, you had to better read our instructions indeed

But we think it could be great the default FTP path of the default ftp user being set to the html dir, and allow the user to change this default path to domain.com dir or even the account dir if the var dir can’t be renamed. We think that this default path would be enough for 7/10 cases.

It’s just the set of the default path. To allow a user to go before it is ok while the var dir can’t be rename.

Pascal

4

Ok, I see what you mean. Make that the default since it will work for 80% or so of the clients and the ones that need to change it can change it.

One example of the reason its good to have include outside the public_html path is if for some reason the PHP engine crashes and your page is displayed in plain text. If that page gets a lot of functions and maybe mysql username and password then those will not be shown b/c they would never be included if PHP crashed. Also, these files can not be reached directly via http request, it is controled through PHP.

5

ha ha ha

Yes exactly. Much better in English and one sentence :wink:

6

  1. The default place for a user is /home/<username> becuase of multi-domain. The original design was so that you could login and see a list of domains that you owned. For a single domain account this can be confusing but as soon as multi-domain is avail it’ll be much more clear to clients.

  2. I agree with both of you, var shouldn’t be renamable and we’ll fix this.

Chris

7

I’ve come up with a workaround for those running proftpd server. This only affects the ftp but it should help. It doesn’t affect sftp or ssh however.

In the global context look for:

  <Directory />
    HideUser  root
    HideGroup root
    HideGroup wheel
  </Directory>

Now after the ‘HideGroup wheel’ line add this:

    HideGroup iworx
  <Limit ALL>
    IgnoreHidden on
  </Limit>

This should all be within the Directory context you were looking at so it should end up looking like this:

  <Directory />
    HideUser  root
    HideGroup root
    HideGroup wheel
    HideGroup iworx
  <Limit ALL>
    IgnoreHidden on
  </Limit>
  </Directory>

What this does is in addition to what was already being done also hide anything owned by the group iworx. However it doesn’t affect the ones owned by the user iworx. In addition there is a Limit context that affects all commands and makes it so that anything that is hidden returns a file not found error. The net effect? This will hide the var folder but nothing else. It is also shielded from being renamed (or deleted or anything else really).