Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id C7B0264FCCE for ; Mon, 18 Aug 2008 16:08:20 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 68561-01 for ; Mon, 18 Aug 2008 16:08:14 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.155]) by postgresql.org (Postfix) with ESMTP id 8A00764FCBF for ; Mon, 18 Aug 2008 16:08:16 -0300 (ADT) Received: by po-out-1718.google.com with SMTP id c31so3919893poi.3 for ; Mon, 18 Aug 2008 12:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=d4BDTAwDogZaoHxhA4kDNaJpWO2b/fJk2WI4hkeYC7Y=; b=DJdq+DiICsBwVM/QnF0qbQU0gf/4hT2ZwiMz4LNBTMQ5vBza8FbO3iJ7MzoeHuEsyY w3fUTnrIvoiBn2nXjXlCvKWGbh0lVUDhZrWaM3eE5J/hULDMlXNXs66K+iOh9zbovwr6 iBRdOwupu3d3PGhjtGJF4tLhl2sT7GUYiwekA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sm6wa9qsXZ5hFQUB/bq0eLB0fV2neUmR1zaylOFaLWYecfFPLn4/EtI21FeSwb16oS ocGV/s/y3lj6CcUPboYwSgy7tuK9ZdHmJ+IZ3f4mM4oLigLiD/p323wa3fJ2FT6Lu6aP KZ9yXv2dy7jZ9WSB8HDtIrB6IdcUS9YO4pKU0= Received: by 10.140.194.21 with SMTP id r21mr3545165rvf.104.1219086494762; Mon, 18 Aug 2008 12:08:14 -0700 (PDT) Received: by 10.141.197.1 with HTTP; Mon, 18 Aug 2008 12:08:14 -0700 (PDT) Message-ID: Date: Mon, 18 Aug 2008 13:08:14 -0600 From: "Scott Marlowe" To: "Thomas Jacob" Subject: Re: Best practice running a shared DB hosting server Cc: "Robert Treat" , pgsql-admin@postgresql.org In-Reply-To: <20080818182430.GB22324@internet24.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1218635097.28547.28.camel@enterprise.ims-firmen.de> <1218642490.28547.50.camel@enterprise.ims-firmen.de> <200808181148.14557.xzilla@users.sourceforge.net> <1219077495.18884.38.camel@enterprise.ims-firmen.de> <20080818182430.GB22324@internet24.de> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200808/80 X-Sequence-Number: 29925 On Mon, Aug 18, 2008 at 12:24 PM, Thomas Jacob wrote: > On Mon, Aug 18, 2008 at 10:49:49AM -0600, Scott Marlowe wrote: >> On Mon, Aug 18, 2008 at 10:38 AM, Thomas Jacob wrote: >> > I've changed my approach by revoking rights to schema public >> > from PUBLIC in the template1, and then granting all rights >> > to again just to the "main" user, and usage rights to >> > the additional users. >> > >> > So people aren't forced to use schemas. >> >> Not sure exactly what you mean. Everything in pgsql lives in a >> schema, whether it's public or another schema. By judicious use of >> the search_path settings you can make the use of such schemas nearly >> transparent to the users, but they're still there. > > Sorry, that was very vague. Some people might just be used > to there being an explicit public schema. This is not very > likely, agreed, but if having access to the public schema is not > a security risk, then there is no need to force users to create additional > schemas if they don't want to. Right, I'd just keep the public schema. the only issue with it is that by default any user who can log into a database can create things there. However, you can revoke those privileges from public then explicitly grant them to the users of that database.