X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 39CD011F65D4; Tue, 18 Apr 2006 06:58:03 -0300 (ADT) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Score: 0.108 X-Spam-Level: X-Spam-Status: No, score=0.108 required=5 tests=[AWL=0.108] Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id a9F2GGEpP5eI; Tue, 18 Apr 2006 06:57:54 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.logix-tt.com (unknown [212.211.145.186]) by postgresql.org (Postfix) with ESMTP id 26FC111F65C4; Tue, 18 Apr 2006 06:57:55 -0300 (ADT) Received: from kingfisher.intern.logix-tt.com (Tba08.t.pppool.de [89.55.186.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id B85B8656CD; Tue, 18 Apr 2006 11:58:54 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id C174E181C1F3F; Tue, 18 Apr 2006 11:58:12 +0200 (CEST) Message-ID: <4444B834.1030107@logix-tt.com> Date: Tue, 18 Apr 2006 11:58:12 +0200 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-sql@postgresql.org Cc: pgsql-admin@postgresql.org, pgsql-general@postgresql.org, pgsql-jdbc@postgresql.org Subject: Re: [JDBC] Thoughts on a Isolation/Security problem. References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archive-Number: 200604/154 X-Sequence-Number: 21323 Hi, Achilleus, Achilleus Mantzios wrote: > Now i am thinking of restructuring the whole architecture as: > - Create one EAR app for every mgmt company > - Create one DB USER for every mgmg company > - Create one SCHEMA (same as the USER) for every mgmt company > (mgmtcompany1,mgmtcompany2,etc...) We're doing a very similar thing here for one of our legacy apps, which luckily does not know anything about schemas, and so the search_path trick does work. However, for most "global" tables we have views with insert/update/ delete rules in the specific schemas, and such shield the application from directly accessing the global data. We even need to mere local and global data this way in some cases. It is ugly, but it works fine and is manageable. HTH, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org