Paul is correct, the multi-tenant stuff has nothing to do with code deployment and tenants don't have access to code. If you use OFBiz in a multi-tenant mode all tenants will be running on the same code base. Whoever is managing that code base could write tenant-aware code so that it only operates for one or more tenants, but that would not be the tenant setting it up, it would be the group who controls the central code base.
The confusion in your question, Ruth, seemed to be the the multi-tenant functionality somehow gives each tenant the ability to add code, and it does not. -David Paul Foxworthy wrote: > Hi Ruth, > > Your bank does not provide you with your own personal mainframe and your own > personal database. Your bank balance is in a row in a table with other > customers' balances above and below, which you should not be able to > discover. We've been living with those risks for decades. > > Of course, an OFBiz user with permissions to log on to OFBiz and use its > services should not have the rights to modify a classpath or upload a Groovy > script. An OFBiz user should not have write permission on anything that is > executable. That applies to single-tenant as well as multi-tenant > situations. It applies to web applications in general, not just OFBiz, not > just Java. If such an exploit were ever found, I would be willing to bet > that a single-tenant OFBiz would be vulnerable as much as a multi-tenant > OFBiz. > > Any OFBiz site that is public-facing (for example, for e-commerce) might > have visitors who are hostile to the owner and seeking to exploit a security > flaw to do damage. That applies to single-tenant as well as multi-tenant > situations. > > Multi-tenancy should not greatly increase the risk of these or other > exploits. You're running pretty well the same code, it's just a matter of > what database you're connected to. > > So I don't see multi-tenant as a totally new or unique situation. It's a > difference of degree, not kind. > > Cheers > > Paul Foxworthy > > > Ruth Hoffman-2 wrote >> Hans, Pierre and several others have been kind enough to outline the >> OFBiz multi-tenant value proposition. >> >> I appreciate this primarily because I can't even count the number of >> times prospective OFBiz users have asked me about it. Now, with this >> background information, I feel comfortable articulating the marketing >> value proposition. >> >> What I still have great angst about, is the security side of >> multi-tenancy. Perhaps someone can clarify or answer this basic question: >> >> What is to stop a hacker or otherwise malicious tenant from writing a >> Groovy script (or Java program that is inserted on the classpath when >> the system is rebooted) that acts as a "trojan horse"? For example, how >> can you stop a savvy tenant from adding a program (or, I could even see >> hacking the Mini-lang since all it is - is interpreted XML statements) >> that monitors (JVM) memory and captures shopping cart objects or >> usernames and passwords of the other tenants? >> >> Really, I'd like to endorse multi-tenant implementations. But I am still >> left with this one - very significant - security question. >> >> Anyone care to respond? Am I missing something here? >> >> Regards, >> Ruth Hoffman >> > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Multi-tenant-Security-tp4336437p4337693.html > Sent from the OFBiz - User mailing list archive at Nabble.com.
