Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 557CF6338CF for ; Wed, 7 Apr 2010 07:45:26 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 81802-01 for ; Wed, 7 Apr 2010 10:45:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mail.postgresql.org (Postfix) with ESMTP id B8FE6633632 for ; Wed, 7 Apr 2010 07:45:13 -0300 (ADT) Received: by bwz8 with SMTP id 8so728858bwz.3 for ; Wed, 07 Apr 2010 03:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f7052/GvnJssLn/1pOG2dm6RhktkLj97E9IPNyE90UE=; b=M/oRjO1CleSRW7jAskZQpgeXdAtLggHEylI/4w+69DZIP7hRpJCo1ugGTC9oXNKLwV kkU4rvaT3hrVWJ2ZSo5sY9F5mDpphvf2Mj3QX+IKsb+xzFJebl8FQyS4a/grs/Uls2XC EuSMmsjjG823+wVqqjbKFBTloELQDPR2VtSHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jB2s/XkoS6vtdLpZkc+AOAafIPWTnxK0q32pJ5/BExV/AC+SHmHZR4AmPiwBZkRW4d 571V58CAMATpry18Ec5yrbUIzQ/RYGhonyMSlwsRHohNZMb62YKtcX0qGyp2NHDm8w2Z Ratp/MGIBKzvFyddwkFXc4EMpCpx2I2MDbc7Y= MIME-Version: 1.0 Received: by 10.204.101.6 with HTTP; Wed, 7 Apr 2010 03:45:11 -0700 (PDT) In-Reply-To: <4BBB6A49020000250003052B@gw.wicourts.gov> References: <4BB774D4.3070306@joeconway.com> <4BBA05E80200002500030493@gw.wicourts.gov> <4BBA6924.5050305@joeconway.com> <4BBB009102000025000304D3@gw.wicourts.gov> <4BBB6A49020000250003052B@gw.wicourts.gov> Date: Wed, 7 Apr 2010 13:45:11 +0300 Received: by 10.204.84.220 with SMTP id k28mr8961963bkl.70.1270637111398; Wed, 07 Apr 2010 03:45:11 -0700 (PDT) Message-ID: Subject: Re: Database level encryption From: Timothy Madden To: Kevin Grittner Cc: Scott Marlowe , Joe Conway , pgsql-admin@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.213 tagged_above=-10 required=5 tests=AWL=-0.103, BAYES_05=-1.11 X-Spam-Level: X-Archive-Number: 201004/62 X-Sequence-Number: 34156 On Wed, Apr 7, 2010 at 1:07 AM, Kevin Grittner wrote: > Timothy Madden wrote: > [...] > But the server needs to read certain data from the database > directory in order to start. =A0In particular, WAL files need to be > read to get a clean start, and those can contain any data from the > database table. =A0Any or all tables may need to be accessed to get > the database to a consistent point on startup. =A0Plus there are all > the system catalogs, including the ones needed to authenticate > users. OK let's put the key logger issue aside from database encryption. I am willing to accept that the server may need to read the list of tables/schema-objects in the database, and some leftover data, in order to start, as long as the leftover data is immediately discarded upon start-up, and as long as it is likely that this data is not a large fraction of the data found in the database. It would still be nice if this check or clean-up could be delayed until such time some user really selects the database for use, and provides a password. I would expect the database (or catalog, I guess, is it ?) to be visible, but any attempt to connect without the password would fail as if user has no rights on the database or the password is wrong. What I perceive as a problem here might be that an encrypted database would automatically need the privileges to be set up so that only the owner can read or connect to it. That is its privileges would have to indicate that even the postgres user can not read it. Except maybe for the names of tables and schema objects, if the server insists that it needs those for a clean start up, and so those shall remain clear text. User authentication should be unrelated to encrypting the database owned by that user. You can think of it as if only the owner can ever connect to such a database, and his/her password is the encryption key, or as if any user that wishes to connect should provide the encryption key first, and then the user name and password. Thank you, Timothy Madden