Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neWWB-0000UY-5f for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Apr 2022 06:30:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1neWW9-0006EA-Su for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Apr 2022 06:30:17 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1neWW9-0006E0-Eu for pgsql-hackers@lists.postgresql.org; Wed, 13 Apr 2022 06:30:17 +0000 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1neWW5-0005Hm-QT for pgsql-hackers@lists.postgresql.org; Wed, 13 Apr 2022 06:30:16 +0000 Received: by mail-wm1-x335.google.com with SMTP id o20-20020a05600c511400b0038ebbbb2ad8so542678wms.0 for ; Tue, 12 Apr 2022 23:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybertec-at.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:comments:mime-version :content-id:content-transfer-encoding:date:message-id; bh=2+vf7mUJFoE57+0+Y30o5iwrO6nGY0qsb88HXArG6u8=; b=t3b6dI+39yN7MTgZ2UyqYdL4RvGHs0l5UFWQIqL0DAtX6GQDXeIy8ewLEpxAhvaHdK 3u9XQbbnERduRniCc9vl1ZRvqTV2IqKjYWhrt1EEFFIer0rxPDD/8EQajlW5oW9RILIa aeQh9UeEfOCA1bkp90dA4eFDiGcYqF+qjvOaO3V5A9whbEMOtbv9m0IjdBEnJU/56pvy W3KzyRkGZsHh/XE77gjOo4mAJb3y0MD+1N4QrZ9ad0KfeDVvW5jopXG4Nbm4sPxJwSjk 7LwmdJ6sHE8uvzyglaa2r3tNI2Q5pHUflOT2f7CpIhrgZeoOb+KOjg/T8gr3+1Z0G/us dYNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :comments:mime-version:content-id:content-transfer-encoding:date :message-id; bh=2+vf7mUJFoE57+0+Y30o5iwrO6nGY0qsb88HXArG6u8=; b=s8AMmS3Xuv/VhOmwvKf6fP/3zcjWT9rMp96Iwb3DoC5MJ/XtbsRm87C9PO39+LR91T sWZiKy7bnkK/TTSFV0e6nFZF/GJPVA+0cAxvBa1i7BJdsIeP6Spg3A1KTsh88LqXrc6g yBEVvD/0mMwHPFpiLeHh350t4OKxGQcbZfWMiMn8IS8hX0De+RYewgvfBWjDb7Ne1zvT i2ivepx7yyw66AHH40m7nJFUF9hW9HMASHQ1VRn7LFAd0CeuuQh+YMonHdnXTiGeTDKx F1OzNsqqHDhw8ar+ZZRrwJbhLuEA47URrZSgEM6a9rRN8+edVU7qEkZL76UmIS9/vDSc xbXg== X-Gm-Message-State: AOAM5328b6DN8ZTtwDUT2+cyibpo0QIAs7l6YHzXJD1jqKUNG60qg+kq K502QD/Jzn3Z/+WgFUpJXPDReg== X-Google-Smtp-Source: ABdhPJzadbsBlT4h7CYrpJuTzTyKbfunrZeA9dpH5voGkVk7S6/UPcUTGNh78ceVcyy0WHV+5fBeJw== X-Received: by 2002:a05:600c:5120:b0:38c:d121:4738 with SMTP id o32-20020a05600c512000b0038cd1214738mr7315826wms.32.1649831412672; Tue, 12 Apr 2022 23:30:12 -0700 (PDT) Received: from antos (85-207-121-76.static.bluetone.cz. [85.207.121.76]) by smtp.gmail.com with ESMTPSA id v1-20020adf9e41000000b00205c3d212easm31708167wre.51.2022.04.12.23.30.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 23:30:11 -0700 (PDT) From: Antonin Houska To: Matthias van de Meent cc: Robert Haas , Stephen Frost , PostgreSQL Hackers Subject: Re: Temporary file access API In-reply-to: References: <4987.1644323098@antos> <20220301143431.GT10577@tamriel.snowman.net> <27013.1646738099@antos> <3146.1649408068@antos> <2132.1649664364@antos> Comments: In-reply-to Matthias van de Meent message dated "Tue, 12 Apr 2022 17:00:24 +0200." X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 27.2.50 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2345.1649831428.1@antos> Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2022 08:30:28 +0200 Message-ID: <2346.1649831428@antos> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Matthias van de Meent wrote: > On Mon, 11 Apr 2022 at 10:05, Antonin Houska wrote: > > > > There are't really that many kinds of files to encrypt: > > > > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_t= he_files_that_contain_user_data > > > > (And pg_stat/* files should be removed from the list.) > = > I was looking at that list of files that contain user data, and > noticed that all relation forks except the main fork were marked as > 'does not contain user data'. To me this seems not necessarily true: > AMs do have access to forks for user data storage as well (without any > real issues or breaking the abstraction), and the init-fork is > expected to store user data (specifically in the form of unlogged > sequences). Shouldn't those forks thus also be encrypted-by-default, > or should we provide some other method to ensure that non-main forks > with user data are encrypted? Thanks. I've updated the wiki page (also included Robert's comments). -- = Antonin Houska Web: https://www.cybertec-postgresql.com