Prevent clients from hijacking each others subdomains

subscribing

Moving this to the Hosting DNS module as discussed in #2466989: Spin off DNS extension.

Moving this back to the hosting issue queue. In the hosting dns module (which is taking shape) I chose to associate DNS zones with sites and aliases, rather than allowing users to enter all domain names themselves (if Bind should manage non aegir domains I feel people should include another file in the bind config for those. aegir should not manage non-aegir zones).

But while testing this, it seems that clients can register sites with subdomains of other clients. So if client 1 owns http://client1.com, client 2 is able to create a website on http://client2.client1.com. I feel this is the responsibility of hosting to prevent this.

I took a stab at this, integrating it in existing workflows as good as possible. Please tell me what you think.

Without the DNS submodule there is not really a concept of domains in Aegir on which we can limit this.

A mitigating factor for non DNS Aegir servers is that the client2.client1.com DNS record would probably not exist ... although it could ... when using things like wildcard records.

Other notes:
- array_slice($url_array, -2, 2); would work for example.com but not for cases like example.co.uk
- I noticed that https://www.drupal.org/project/hosting_dns only lists a dev release for the 1.x branch... while the latest code is in 3.x
- about "I chose to associate DNS zones with sites and aliases", That would rule out some usecases :(, and would it work for multiple sites under the same domain?

Without the DNS submodule there is not really a concept of domains in Aegir on which we can limit this.

I assumed this would work with an external DNS server as well (though I've never tried it). But the logic applies regardless of DNS settings. If one clients owns the site example.com there should not be a possibility for another client to obtain sub.example.com either as domain name or alias. (It should be made impossible to create a site with that name.)

array_slice($url_array, -2, 2); would work for example.com but not for cases like example.co.uk

True, I did not think of that... But there should be another way to obtain a root domain. I'll come up with something.

I noticed that https://www.drupal.org/project/hosting_dns only lists a dev release for the 1.x branch... while the latest code is in 3.x

That is because the 3.x branch was not functioning until a week ago (and code on drupal.org is still a bit behind). I now have it working locally and will publish a dev version soon. (As the project description reads, the 1.x version is the hosting and provision implementation as extracted from aegir 3.6, provided there for backup and in case you decided to remove the modules from hosting :) ).

about "I chose to associate DNS zones with sites and aliases", That would rule out some usecases :(, and would it work for multiple sites under the same domain?

A client is capable of registering as much sites on the same domain as he desires (as long as the alias or domain is not in use for another client or other owned site). The DNS configuration will be split over the different domains though. As you can see in the screenshot there is a DNS section within each site, with the aliases as secondary tabs (though that will change as it requires a cache clear for them to show up).

The only use-case that it blocks would be for domains that are managed outside of aegir. If you are a 'poweruser' that pulls that off, I don't think editing the Bind config file to include another zone would be much of a problem. IMHO allowing people to manage domains that are not part of their client (or not even part of aegir) can break more than it adds.

If you believe there is more, please elaborate on those use-cases :)

Helmo, if you can think of other use-cases, please report them in #2466989: Spin off DNS extension I can look at those this weekend. (Let's keep this issue relevant to the fact that different clients can register sites with overlapping url's.)

As for the detection of root domains and TLD's, it seems the only real reliable way would be the use of TLD lists like https://publicsuffix.org (and libraries such as https://github.com/layershifter/TLDExtract to process them, because these lists contain wildcards and exceptions...). I doubt I can convince you to include that in hosting_site, but can't think of alternatives either..

Thinking of this some more, I guess it would make sense to perform a full match for the end of the domain.

So if client 1 owns 'domain.com', or 'domain.co.uk', no other client (except client 1) will be able to register a domain that ends in that exact pattern.
This does not cover the cases where the initial registered domain is 'sub.domain.nl', so somebody else would still be able to register 'domain.nl'. I however think this is an edge case.

This at least provides some protection with having to deal with lists.

Please have a look at attached patch.

It will break down some.very.long.domain.name.com at every dot checking the availability of:some.very.long.domain.name.com
very.long.domain.name.com
long.domain.name.com
domain.name.com
name.com
com

If somebody has any of those domains, the new domain will not be created.

As long as nobody registers com (or co.uk) this should work fine I guess.

Nice. The patch works as expected.
And tests pass: https://travis-ci.org/aegir-project/hosting/builds/172893776

I think we need to improve it a bit more though.

One is to by avoiding duplication between hosting_alias_allow_domain() and hosting_site_allow_domain()

And I do feel we need a way to override this. With this patch it's not even possible for user 1 to create such a site.
One scenario I can think of is having a domain with a wildcard record to the Aegir server witch is used as test address for multiple clients until their real domain gets activated there.

One way could be a whitelist string of domains that can be used by anyone, a special permission that could be handed out to a trusted user ( and would apply to User 1)

Thanks, your remarks make sense. Admins and other selected users should be able to bypass this check.

I'll try to remove the duplication (one of the queries previously was in db_query syntax but now with db_select they only differ one or 2 lines.
I'll add a permission to bypass the root domain usage check (obviously the check for the exact match should remain in place).
I will see if I can incorporate some whitelisting, I recon the need, but do not know where and how to fit it in.

This feels like something better suited in contrib, maybe Hosting Tasks Extras.
We could use a hook to allow module authors to limit allowed domains. I fear this being default behavior will cause confusion.

I guess it depends on how you look at it. From a single administrator user I agree that this does not make a lot of sense. But the whole hosting_client module that comes pre-installed and all, makes that for me aegir feels somewhat like the open source alternative to DirectAdmin, cPanel, etc... In that case I feel this is a must-have feature.

So what do you want to be?

Lets add a config setting for this. e.g. 'hosting_client_restrict_domain_choice'. with the description "As a policy a hosting_client user is not allowed to create a site on a domain or subdomain thereof that is already in use by another client."

The extra checking can then happen in a hook_allow_domain implementation in hosting_client.
This way we can keep the hosting_alias and hosting_site implementations of the hook focused on avoiding duplicate domains being used.

Please have a look at attached patch. It comes with a hosting_client setting (I felt hosting_client_subdomain_owner_check was better :) ) and an additional user permission to bypass the check if it is enforced.

I kept some changes in the other modules to make sure hosting_domain_allowed always gets the same data structure.

I am still not sure about how to implement the whitelist from #14.

It's been way too long :(

Setting status since we need to figure something out about a whitelist.